Page 1 of 1
Like-Named Constants and Variables
Posted: Sun Jan 22, 2006 8:07 am
by chris319
IMO this code should not even compile:
Code: Select all
OpenConsole()
#my_number = 666
PrintN(Str(#my_number))
my_number.l
my_number = 123
PrintN(Str(my_number))
Input()
End
Posted: Sun Jan 22, 2006 8:37 am
by Straker
I believe that the constants are replaced with actual values during the pre-compile, so it compiles because the compiler sees this instead of your original code:
Code: Select all
OpenConsole()
PrintN(Str(666))
my_number.l
my_number = 123
PrintN(Str(my_number))
Input()
End
Posted: Sun Jan 22, 2006 8:40 am
by PB
Straker is right. No problem with that code at all.
Posted: Sun Jan 22, 2006 8:44 am
by netmaestro
#num, num, *num and num$ are all unique variable names. They all have different meanings and the only wrinkle you have to worry about is the case of:
Structure Stuff
x.l
*y
EndStructure
newvar.stuff
y is referenced:
newvar\y, not with newvar\*y
It's a unique case.
Posted: Sun Jan 22, 2006 12:14 pm
by remi_meier
I hope that changes!
Posted: Sun Jan 22, 2006 12:52 pm
by chris319
I'm saying the compiler/precompiler shouldn't allow constants and variables to have the same name. Try this in any other BASIC compiler:
const my_number = 123
my_number = 666
For that matter, try this is PB:
my_number.l = 123
my_number.f = 3.14159
Why should like-named variables and constants be allowed but not like-named variables of different types? No "maximum flexibility" there.
Because PureBasic is "special", people sometimes forget to prepend the # character to the constant name, leaving them with a stray like-named variable.
Posted: Sun Jan 22, 2006 1:05 pm
by PB
> try this in PB:
> my_number.l = 123
> my_number.f = 3.14159
Results in this error:
Code: Select all
---------------------------
PureBasic
---------------------------
Line 2: Variable already declared with another type: my_number
---------------------------
OK
---------------------------
So what's the problem?
Posted: Sun Jan 22, 2006 1:25 pm
by Dare2
Hi chris319,
Look on the bright side.
Consider a big prog with:
- const intervalValue = 123
and thousand lines away:
- ToGood = intervalValue * intervalBase
Nothing leaps out and says "constant". good discipline suggests prefixing to give clues, you would probably want to call it
- const constIntervalValue = 123 ' or even constIntIntervalValue
so you know it is a constant (and an integer).
Just MHO, but the PB way is pretty good. It is instantly clear when you are dealing with constants because of the leading #, which is also part of the name.
Posted: Sun Jan 22, 2006 1:29 pm
by freedimension
The * of Pointers, $ of Strings and # of Constants are part of the name, therefore #Placeholder <> Placeholder <> *Placeholder <> Placeholder$
So where's the problem?
Posted: Sun Jan 22, 2006 7:31 pm
by chris319
PB wrote:> try this in PB:
> my_number.l = 123
> my_number.f = 3.14159
Results in this error:
Code: Select all
---------------------------
PureBasic
---------------------------
Line 2: Variable already declared with another type: my_number
---------------------------
OK
---------------------------
So what's the problem?
The problem is that this code does
not generate an error:
Code: Select all
#my_number = 666
my_number.l = 123
Do you see the inconsistency in this?
Posted: Sun Jan 22, 2006 7:45 pm
by Fred
As freedimension said, it's part of the name, so 2 differents symbols.
Posted: Sun Jan 22, 2006 8:30 pm
by PB
> The problem is that this code does not generate an error
Well, I was actually replying to your invitation to run the .l and .f example,
which does in fact give an error about duplicate variable names.
> people sometimes forget to prepend the # character to the constant name
Not PureBasic's problem. The # character is part of the name, so what you're
saying is no different to someone using two variables called "boo" and "boot"
and then forgetting to add the "t" when referring to the second one. Should
PureBasic not allow both these names too?
Posted: Sun Jan 22, 2006 8:36 pm
by Trond
Or writing a word starting with c when they should write the word meaning the wife of the uncle.
*ducks and runs away*
Edit: The #, as opposed to the t, is not really pronounced, that's the difference. On the other hand, I think we need to disallow "aunt" then, until we start pronouncing the other word also.