| Author |
Message |
Paul_L
Guru
Joined: 03/03/2016
Location: United StatesPosts: 769 |
| Posted: 10:11pm 12 Jul 2017 |
 Copy link to clipboard |
 Print this post |
|
The need to predefine variables before they're used can be a little confusing.
OPTION EXPLICIT
DIM f$,g$,h%,x%
' do some stuff with f$,g$,h%
x%=whatsit%(f$,g$,h%)
function whatsit%(a$,b$,c%)
' do something with a$,b$,c%
if c%>5 then whatsit%=1 else whatsit%=0
end function 'whatsit(a$,b$,c%)
I know that f$, g$ h% and x% are globals and that a$, b$ and c% are local to the function even though they do not appear after a LOCAL command.
My question is where is the variable whatsit% declared? It seems to be implicit in the function definition but does that definition in the function establish its existence in the prior calling code or do I need a DIM whatsit% before the call x%=whatsit%(f$,g$,h%)?
Paul in NY
|
| |
Grogster
Admin Group
Joined: 31/12/2012
Location: New ZealandPosts: 9748 |
| Posted: 11:50pm 12 Jul 2017 |
Copy link to clipboard |
Print this post |
|
Someone more in the know then me will clarify, but the way I understood functions was that when you declare the function, that also defines the 'variable' in the process.
IE: You don't need to define a variable that is returned as part of a function. That is MY interpretation of events, as in you example above, function whatsit% defines a function, which will return it's result in the variable whatsit%
I think this is the only situation where you DON'T define the variable when using OPTION EXPLICIT, and all other 'normal' variables DO have to be specifically declared.
Smoke makes things work. When the smoke gets out, it stops! |
| |
Paul_L
Guru
Joined: 03/03/2016
Location: United StatesPosts: 769 |
| Posted: 12:15am 13 Jul 2017 |
Copy link to clipboard |
Print this post |
|
Hi Grogster, that's what I assume is the case but I want to be sure.
Paul in NY
|
| |
GoodToGo!
Senior Member
Joined: 23/04/2017
Location: AustraliaPosts: 188 |
| Posted: 01:46am 13 Jul 2017 |
Copy link to clipboard |
Print this post |
|
Thinking of whatsit% as a variable could possibly get you into strife by confusing it with real variables. No DIMming required.
Maybe think of it as a special sub that returns a value. That value can be placed into a variable, like your x%=whatsit%(f$,g$,h%) or worked on directly like "IF whatsif%(f$,g$,h%) = "Something spiffy" then Print "Top Stuff!".
Spent many hours of my life I won't get back working that one out when I started playing with MM's..... 
My thoughts/dribblings anyway.
GTG! 
...... Don't worry mate, it'll be GoodToGo! |
| |
Paul_L
Guru
Joined: 03/03/2016
Location: United StatesPosts: 769 |
| Posted: 09:38am 13 Jul 2017 |
Copy link to clipboard |
Print this post |
|
@GTG! I guess the tipoff that whatzit% is not really a variable might be if you can't use it in an equation, or can you?
I wonder if something like this would work?
OPTION EXPLICIT
DIM f$,g$,h%,x%
' do some stuff with f$,g$,h%
x%=whatsit%(f$,g$,h%) * h% '<<<<<<<<<<<<<<
function whatsit%(a$,b$,c%)
' do something with a$,b$,c%
if c%>5 then whatsit%=1 else whatsit%=0
end function 'whatsit%(a$,b$,c%)
Paul in NYEdited by Paul_L 2017-07-14 |
| |
JohnS
Guru
Joined: 18/11/2011
Location: United KingdomPosts: 4126 |
| Posted: 10:52am 13 Jul 2017 |
Copy link to clipboard |
Print this post |
|
Should be fine.
John |
| |
robert.rozee
Guru
Joined: 31/12/2012
Location: New ZealandPosts: 2461 |
| Posted: 07:41pm 13 Jul 2017 |
Copy link to clipboard |
Print this post |
|
you can always not use OPTION EXPLICIT and then mmbasic will create the variables as you use them.
while i was in favour of OPTION EXPLICIT when it was first introduced, over time i've been changing my views - it attempts to eliminate one set of problems (people mis-spelling variable names), but then introduces a whole new level of complexity that can be just as bad.
having said this, there are arguments for having a new version of "BASIC" built from the ground-up where variables and types are always explicitly declared. but then would this new language still be "BASIC"? or would it be 'interpreted PASCAL with BASIC-like syntax'?
btw, I  PASCAL
cheers,
rob :-) |
| |
Paul_L
Guru
Joined: 03/03/2016
Location: United StatesPosts: 769 |
| Posted: 08:49pm 13 Jul 2017 |
Copy link to clipboard |
Print this post |
|
Hi Rob. Ah yes, the eternal ongoing debate over typing of variables!
Explicit typing of variables is a mixed bag. If you don't use OPTION EXPLICIT you should probably lean heavily on MMEdit to generate a report on variable usage and scan the resultant table carefully for typos. (Thanks Jim!)
Typing gets even weirder when you start having forced mixed types. This comes up in database applications like dbase and mainframe DB2 over CICSPROD. Some variables are persistent because they really exist in multiple sets outside of the program code in a storage file somewhere. Other variables created in the code are transitory. You wind up thinking of them as VARS and memvars and you have to keep them separate in your thinking.
The memvars are handled in the usual way with simple assignments (x=3:y=4). Changing the value of a VAR needs some sort of more complicated procedure because you have to write the value to a disk file. Fox developed an interesting way of doing it.
When you aim a pointer to a specific record Fox reads all the variables in the record into memvars automatically (m.A=A: m.B=V : m.C=C .... ). You then modify the memvars (m.A=A+1 : m.B=x*m.A .... ). When you're done playing with the memvars you issue a command (COMMIT ?) and Fox writes the changed m.vars into the record.
That's how we tried to keep track of every maintenance task done by 9000 mechanics on 500,000 individual components on 245 aircraft at Pan Am, every piece of freight including its weight and where it was located in the aircraft cargo compartment, every passenger and where they sat (we tried to guess how much the girls weighed), and the color of the stewardess's unmentionables.
That was a lot of memvars, VARS, records and FUN!
Paul in NY
|
| |
Grogster
Admin Group
Joined: 31/12/2012
Location: New ZealandPosts: 9748 |
| Posted: 04:22pm 14 Jul 2017 |
Copy link to clipboard |
Print this post |
|
....funny....it does not sound like fun.....
Smoke makes things work. When the smoke gets out, it stops! |
| |
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.