DIM - AS - VARIABLE TYPE likely bug

[bartok]

I have found a probable bug using AS.

Writing, for example:

DIM A%

it's the same then writing

DIM A AS INTEGER

But it is possible to write:

DIM A%
DIM A$

but we incur into a "Name already in use" error if we write:

DIM A AS INTEGER
DIM A AS STRING

Example:

Code: (Select All)

OPTION _EXPLICIT

DIM A$

DIM A% '--------------------------> working



'DIM A AS STRING

'DIM A AS INTEGER'  ---------------------> not working



A$ = "hello"

A% = 2



PRINT A$, A%

[SMcNeill]

No bug.  That's how BASIC is designed.  Just like CONST, once you explicitly define something, it locks out other definitions.

[bartok]

No bug.  That's how BASIC is designed.  Just like CONST, once you explicitly define something, it locks out other definitions.

So, what's the difference in defining a variable as

DIM A AS INTEGER

compared to

DIM A%

?

[Kernelpanic]

No bug.  That's how BASIC is designed.  Just like CONST, once you explicitly define something, it locks out other definitions.

So, what's the difference in defining a variable as

DIM A AS INTEGER
compared to
DIM A% 
?

There is no difference in the matter. A declaration like *)"A%" is the way the old Basic freaks write, and it's hard to break away from something like that. The same applies to "Option _Explicit". 
It didn't exist in QB, and declarations with "Dim" only had the benefit of not having to constantly write in the program: A% here, A% there, and so on. But spelling mistakes were still not reported.
*)Only A%, not Dim A%

For example:

Code: (Select All)

'Without -Option _Explicit-, 3. Mai 2024



Dim As Integer eingabe, summme



eingabe = 4

summe = eingabe * 3

Print summe



Print

'Spelling mistake

summe = engabe * 4

Print summe



End

[bartok]

No bug.  That's how BASIC is designed.  Just like CONST, once you explicitly define something, it locks out other definitions.

So, what's the difference in defining a variable as

DIM A AS INTEGER
compared to
DIM A% 
?

There is no difference in the matter. A declaration like "Dim A%" is the way the old Basic freaks write, and it's hard to break away from something like that. The same applies to "Option _Explicit". 
It didn't exist in QB, and declarations with "Dim" only had the benefit of not having to constantly write in the program: A% here, A% there, and so on. But spelling mistakes were still not reported.

For example:

Code: (Select All)

'Without -Option _Explicit-, 3. Mai 2024



Dim As Integer eingabe, summme



eingabe = 4

summe = eingabe * 3

Print summe



Print

'Spelling mistake

summe = engabe * 4

Print summe



End

Ok, thank's. In order to not use A% here, and A% there, but only A instead, you have to define A integer as DIM A AS INTEGER. With A% it doesn't work.

[bplus]

first of all, unless you are using option _explicit you don't have to dim single varaibles before using them
dim a%
or
dim as integer a
or
dim a as integer
or
defint a-z
or
redim a%
or
redim as integer a
or
redim a as integer

7 different ways to make a an integer type

btw if you start dim as integer you can list a bunch of variables to dim as integer
dim as integer a, b, c, d
use as first after dim though so all a, b, c, d are integer

dim a as integer, b, c, d
makes a integer but b, c, d will use default single type

again, without option _explicit, you can just start using a% ;-)) and thats fine for a little code snippet specially
it will be 0 until you assign another value to it

it is good programming form to define your variables before using them and option _explicit will tell you immediately if you mistyped or are trying to use an undefined variable.

you do have to dim arrays with > 11 items

Code: (Select All)

For i = 0 To 10
    arr(i) = i ' ha ha free pass from dim
Next

[bplus]

but we incur into a "Name already in use" error if we write:

DIM A AS INTEGER
DIM A AS STRING

ah, there is no suffix for qb64 to tell the differenece between the 2 a's

this lets you define everything as a type unless you explicitly say something different
DefInt A-Z
Dim A As String

[bartok]

but we incur into a "Name already in use" error if we write:

DIM A AS INTEGER
DIM A AS STRING

ah, there is no suffix for qb64 to tell the differenece between the 2 a's

this lets you define everything as a type unless you explicitly say something different
DefInt A-Z
Dim A As String

I have understood. 
IMO, QB could have been programmed in a way in which the suffix of the varible "A" definied with "DIM A AS INTEGER" was "%", as it is in the case of "DIM A%", considered that in both the ways we define exactly the same variabile. But QB is conceived so that we can have:
DIM A%
DIM A!
DIM A$
DIM A&
etc,
but we cannot have
DIM A AS INTEGER
DIM A AS SINGLE
DIM A AS STRING
DIM A AS LONG
etc.


The only reason I found for this, is that if we use "AS" instead of the suffixes, then in the code is possible to use variable name without having to add the suffix each time and, in order to be able to do that, only one "A" must be allowed.

But finally, even if at first this could seem a simplification, actually I prefer to use suffixes for 2 reasons:
1. We could have variables that actually are exactly the same thing and therefore should have the same name. For example a coordinate X, that it is integer(%) or single(!) depending if we are on a view port coordinate or in physical screen coordinate. So, using (AS) it will be compulsory to use different variable name, but I don't find anything clearer than the possibility of using X% and X!;

2. I find that presence of the suffixes actually makes the code more readable.

So, I think is preferable to DIM variables and arrays with suffixes, avoiding the use of AS.

[bplus]

but we incur into a "Name already in use" error if we write:

DIM A AS INTEGER
DIM A AS STRING

ah, there is no suffix for qb64 to tell the differenece between the 2 a's

this lets you define everything as a type unless you explicitly say something different
DefInt A-Z
Dim A As String

I have understood. 
IMO, QB could have been programmed in a way in which the suffix of the varible "A" definied with "DIM A AS INTEGER" was "%", as it is in the case of "DIM A%", considered that in both the ways we define exactly the same variabile. But QB is conceived so that we can have:
DIM A%
DIM A!
DIM A$
DIM A&
etc,
but we cannot have
DIM A AS INTEGER
DIM A AS SINGLE
DIM A AS STRING
DIM A AS LONG
etc.


The only reason I found for this, is that if we use "AS" instead of the suffixes, then in the code is possible to use variable name without having to add the suffix each time and, in order to be able to do that, only one "A" must be allowed.

But finally, even if at first this could seem a simplification, actually I prefer to use suffixes for 2 reasons:
1. We could have variables that actually are exactly the same thing and therefore should have the same name. For example a coordinate X, that it is integer(%) or single(!) depending if we are on a view port coordinate or in physical screen coordinate. So, using (AS) it will be compulsory to use different variable name, but I don't find anything clearer than the possibility of using X% and X!;

2. I find that presence of the suffixes actually makes the code more readable.

So, I think is preferable to DIM variables and arrays with suffixes, avoiding the use of AS.

yes having suffix makes clear what type and wont let you forget

but me, i hate to type, specially those keys that require the use of shift thats 3 keys for a% and the last 2 have to be aligned in time, oh so much more work (specially if your shift key is broken) ;-))

[Kernelpanic]

@bartok - I don't want to offend you, but are you sure that programming is right for you?
I have now looked at your questions and comments, and in my opinion, since 2022 until today, you haven't understood that programming has nothing to do with philosophical considerations.

Sometimes to chose a solution rather then an other could be a philosofical issue, but sometimes is not.

https://qb64phoenix.com/forum/showthread...ght=bartok

My humble recommendation: Buy a book about what programming means, such as: Code Complete, Version 1

The standard work on programming