Like-Named Constants and Variables

[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

[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

[PB]

Straker is right. No problem with that code at all.

[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.

[remi_meier]

I hope that changes!

[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.

[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?

[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.

[freedimension]

The * of Pointers, $ of Strings and # of Constants are part of the name, therefore #Placeholder <> Placeholder <> *Placeholder <> Placeholder$

So where's the problem?

[chris319]

> 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?

[Fred]

As freedimension said, it's part of the name, so 2 differents symbols.

[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?

[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.