Bug? Duplicate public variable allowed, with different definitions

[JohnK]

Summary:
I have found that a class allows having duplicate definitions of the same public variable; as in name and type.

For example, the following was compiling successfully without any warnings or errors. I quickly tested, and you can also assign different default values as well; which would possibly be the source of a hard to find bug.

Reproduction Steps:
This was an existing class, but I am guessing you could simply add a new class, with similar code to the following.

Sub Class_Globals
    Public Field1 as String
    Public Field2 As String = "FIRST DEFINITION"
    Public Field2 As String = "DUPLICATE"
    Public Field3 As String
End Sub

I am using an existing project for me, so have not tried "reproducing" the error beyond my specific project and class.

Actual Behavior:
The project compiles successfully, without errors or warnings.

Expected Behavior:
I would expect the build to fail with an error that there is a duplicate definition.

 

[Erel]

The code you posted is valid. I don't see different definition here. It is allowed to redim variables as long as the type is the same.

 

[JohnK]

The code you posted is valid. I don't see different definition here. It is allowed to redim variables as long as the type is the same.

I disagree. If I have a class, I should not be able to declare the same variable twice, even if the data types are the same with different default values. The default value is part of the property definition. Does anyone else have an opinion?

Thinking of a large class, with many public variables, if I have a default value assigned, with code somewhere else in the project depending on that specific value, being able to redefine the variable a second or even a third time, could lead to bugs in my code. I think it would be more common with projects with multiple people working on it (one guy defines one default value and depends on that value, the other with another that also depends on the other defined default value, with no errors/warnings).

At the very least, I think a warning should be generated highlighting I have done such.

Another way to look at it is, what programming benefit would there be in the above example of being able to define the same variable with different default values? Im serious, how can I take advantage of this?

 

[toby]

I agree with @JohnK. I just ran into a similar problem in my current app. For simple projects, the problem is obvious, but for large production ones, it would be hard to find. The IDE should at least give some warning message.

@Erel, could you show us the benefits of this behavior with some sample code?

 

[stevel05]

A big plus is that you can create a global array of unknown size, then redim it when you know the actual size, you can also use a dim in a loop with the same variable name to create objects to be stored elsewhere. I am sure there are others.

 

[toby]

A big plus is that you can create a global array of unknown size, then redim it when you know the actual size, you can also use a dim in a loop with the same variable name to create objects to be stored elsewhere. I am sure there are others.

I don't see any benefit I can get in the following sub:

Sub Process_Globals
    'These global variables will be declared once when the application starts.
    'These variables can be accessed from all modules.
    Dim x As Int=1

 
    '''''''''''''''''''''''''''''''
    ''a lot of code here
    ''''''''''''''''''''''''''''''''
 
    'Assuming I don't realize that x has been declared already
    'so I declare it again with different value
    Dim x As Int=2

End Sub

When reading the above code, if I miss the second declaration, I would think x's value is 1, leading to hard-to-find bug.

 

[stevel05]

If you give variables a meaningful name, this issue all but goes away. The only time I use X,Y,I etc. as variable names is as an index in a loop or in a Sub where it's scope is limited, certainly not as a global variable.

 

[toby]

If you give variables a meaningful name, this issue all but goes away. The only time I use X,Y,I as variable names is as an index in a loop or in a Sub where it's scope is limited, certainly not as a global variable.

I was just trying to keep the sample code as simple as possible. You could give it a whatever name you want and the problem still exists.

 

[stevel05]

Of course you can, if you want to make it harder to read and maintain.

 

[MarkusR]

Does anyone else have an opinion?

i would expect this usage, but not dim twice

Dim x As Int=1
ReDim x As Int=2

and here a compiler error message

Sub Class_Globals
    Public Field2 As String = "FIRST DEFINITION"
    Public Field2 As String = "DUPLICATE"

you can also use a dim in a loop with the same variable name to create objects to be ..

u used this

 

[Star-Dust]

It is neither a matter. You are confusing the declaration with the definition and then the re-declaration with the re-definition

(See https://en.m.wikipedia.org/wiki/Declaration_(computer_programming) )

an thing is to declare the type of a variable and another thing to define its size and value

for example, a variable can be defined as an Array without specify size

Dim A() Ad Int

But then in the run of the program you could assign a dimension to the values with the same DIM instruction

Dim A(1) as int = Array as int (115)

it is not a new type declaration, the type of data has not changed, but the size is being defined and a value is being assigned.

You can not declare

Dim A ad Double

For those who do not know this way is also allowed in Java, basic and other languages

 

[Erel]

@Erel, could you show us the benefits of this behavior with some sample code?

This is not a bug. This is allowed in B4X language. You can post a feature request to add a warning about it.

 

[Cableguy]

As said above, giving meaning full names helps minimize this issue, and further more, the B4X IDE allows you to easily find all "samename" code lines by just high lighting the variable name ( being it a true variable or an object like a control, node, etc).
Both combined will make it very easy to track down any code "errors" (quotes express to mean they are not real errors).