[Wish] Code Modules - using without prefix

[Jost aus Soest]

It would be very nice to be able to use functions and variables declared in static modules without prefixing these objects with their module name, e. g. not more in this way

var1 = myModule.var2
var3 = myModule.doSomething(var4)

but in future shorter in this way:

var1 = var2               '<-- var2 belongs to myModule
var3 = doSomething(var4)  '<-- doSomething belongs to myModule

Mayby we can introduce a Java-like declaration, e. g.:

import myModule

 

[kickaha]

It is a bad idea to do this, as it would lead to errors if you had variable names or functions repeated in different modules.

Much better to keep them as they are so that modules are independant of the main code.

 

[Jost aus Soest]

It is a bad idea to do this, as it would lead to errors if you had variable names or functions repeated in different modules.

Much better to keep them as they are so that modules are independant of the main code.

Java has no problems with such modules/classes. So why shouldn't we have them in b4a?

Hint: It is still allowed to prefix the imported functions/vars with the module name (in "double cases", where it's sometimes necessary).

 

[thedesolatesoul]

Java has no problems with such modules/classes. So why should we have them in b4a?

Might as well just use Java then

Hint: It is still allowed to prefix the imported functions/vars with the module name (in "double cases", where it's sometimes necessary).

So this is a case of exclusion vs inclusion. I doubt it is very hard to type the module name everytime you want to access it. But better to be safe than sorry.

 

[kickaha]

Java has no problems with such modules/classes. So why should we have them in b4a?

Hint: It is still allowed to prefix the imported functions/vars with the module name (in "double cases", where it's sometimes necessary).

So in your world you would like to alter the fundamental way that modules work in B4A so that you can imagine you are programming in java?

I fail to see any real advantage to your proposal (although I am sure you will manufacture some) and can see lots of disadvantages.

 

[Jost aus Soest]

So in your world you would like to alter the fundamental way that modules work in B4A so that you can imagine you are programming in java?

No, this changes nothing fundamental!
But why do you think so? I havn't sayed anything about changing any already existing code.
BTW: Also in Visual Basic I'm used to avoid redundant code, Java was only one example of most programming languages.

I fail to see any real advantage to your proposal

For example: Much shorter code. Especially useful for reusing utility subs.
And very helpful for reorganizing subs (e. g. moving a sub from an general "utility"-module to a specialized "string"-module etc. pp.), without having to change all the projects, that use these subs.

I [...] can see lots of disadvantages.

Please, tell me only one, taking into account, that you don't have to use this feature! Don't forget, that you can still use module-prefixes.

 

[kickaha]

OK, a disadvantage:

Lets say I am writing a program that needs multiple devices connected to the desktop. I notice that Erel (nice man that he is) has done the legwork with his B4AServer utility (that includes a code module) so I import this into my app and it works!

So then later in my code I insert a sub called "SendMessage". Now a sub of this name exists in the B4AServer module (which I am not aware of as I did not study ALL the code) so how does the system resolve this?

To take this even further, what if I then import another third party code module that also has a "SendMessage" sub?

No doubt your answer will be

Don't forget, that you can still use module-prefixes.

but that then invalidates any usefulness of your proposal, as I would still have to use the prefix to ensure that I am calling the right module, and the system would still need to resolve the ones without a prefix.

In the present system I can happily import code modules as stand alone items without concern, I would not like to see a situation where importing a module could potentially break my existing code.

As for

Much shorter code. Especially useful for reusing utility subs.

Shorter code I grant, but your system is LESS useful for reusing utility subs for the reasoning given above.

 

[Erel]

Any features have some advantages and some disadvantages. There is no point in arguing about all suggested features.

This is a completely reasonable request.

 

[kanaida]

If I can make a suggestion, typically I use the "with" statement for stuff like that in vb languages, then you keep the name of what you're working with as well visually, but you didn't have to type it's name over and over

with SomeObjectOrType
.SomeProperty = 23
.DoSomething()
.Whatever
End with

Import also works well as mentioned above, although it may be harder in practice to implement into b4a. Just guessing here because of other code involved for colors, and error highlighting etc..

 

[naruto]

Didn't know you could use "with" in vb. That sounds like a nice way of solving it.

 

[rbsoft]

It would be very nice to be able to use functions and variables declared in static modules without prefixing these objects with their module name

I understand Jost's wish, I found it a bit awkward too when starting with B4A. But there are also advanteges to it. If you don't remember the name of the sub or variable exactly you can just type ...

mymodule.

...and get a list of subs and vars in the module.

I guess it is all what you are accustomed too.


Rolf

 

[Jost aus Soest]

If you don't remember the name of the sub or variable exactly you can just type ...

mymodule.

...and get a list of subs and vars in the module.

You're right, the context sensitive coding is very useful!
But this trick would still work with my wish fulfilled (as in VB).