UseModule to allow conflicting names

[Trond]

I think it would make more sense to allow several UseModule with conflicting names, and simply not import those names. They would have to be accessed with the full prefix. Because after a short while there will be a lot of conflicts regarding "standard" functions such as New() and Free().

If the name is already declared in the global scope it should still give an error (like now).

Code: Select all

DeclareModule A
  Declare New()
EndDeclareModule

Module A
  Procedure New()
    Debug "A"
  EndProcedure
EndModule

DeclareModule B
  Declare New()
EndDeclareModule

Module B
  Procedure New()
    Debug "B"
  EndProcedure
EndModule


UseModule A
UseModule B ; Error

[GPI]

I think it would make everything more difficullty for beginners.

But maybe a ImportModul <Modulname>, <variable,procedure,structure,interface, dim, list> would be nice, only import one thing out of the modul.

Or a new keyword in the declare-header like "NoUse" and "EndNoUse" - all things in this section will not be imported with UseModule.

But my personal opinion: I like KISS - Keep It Simple Stupid.

Rename the New from Module A in ANew(), and the New from Module B in BNew()

[DontTalkToMe]

related ==> http://www.purebasic.fr/english/viewtop ... =3&t=55236

[netmaestro]

My opinion is that implementing this idea would introduce more problems than it solves. As the OP points out, allowing multiple UseModules with conflicting names would force the coder to qualify the command with a <modulename>:: prefix and if you have to do that, what's the point of UseModule? If you're going to be qualifying the commands anyway, you can forget about UseModule.

Currently, the compiler will behave in a way that should satisfy most people interested in this, and that's achievable with the use of UnUseModule:

Code: Select all

UseModule A
New()
UnuseModule A

UseModule B ; No more error
New()

Which shows that the only real limitation we're hitting is multiple UseModules active at the same time with conflicting procedure names. I submit that implementations of UseModule should be considered more or less mutually exclusive and the coder should never have to keep up with more than one module being active at a time.

[Little John]

But my personal opinion: I like KISS - Keep It Simple Stupid.

I like KISS, too.
And the most simple and straightforward method in this context is IMO:
Just forget about UseModule(), and use the full name which starts with the respective module prefix instead.
Voila!

[Trond]

Rename the New from Module A in ANew(), and the New from Module B in BNew()

That defeats the whole point of using modules. If they had separate names I wouldn't need to put them in a module in the first place.

As the OP points out, allowing multiple UseModules with conflicting names would force the coder to qualify the command with a <modulename>:: prefix and if you have to do that, what's the point of UseModule? If you're going to be qualifying the commands anyway, you can forget about UseModule.

Because most modules will have some name clashes (such as New(), Create(), Delete(), Free(), Min(), Max(), etc). But these will only be a small fraction of the available commands in the module. Most names will not clash.

Just forget about UseModule(), and use the full name which starts with the respective module prefix instead.

Again, it defeats the purpose of having a module, as I could just prefix all names with the module name instead.

[idle]

I think usemodule could be more useful if it allowed nesting, it might make code harder for users to follow
but as it us usemodule isn't really that useful other than convenience.

so

Code: Select all

  
 UseModule A
 New() 
 UseModule B 
   New() 
   Free()
   UnuseModule B 
   Free() 
 UnuseModule A

[helpy]

Just forget about UseModule(), and use the full name which starts with the respective module prefix instead.
Voila!

Yes! This is also my way to use modules.

I also started to avoid the global scope

Code: Select all

XIncludeFile "moduleA.pbi"
XIncludeFile "moduleB.pbi"

DeclareModule Application
	EnableExplicit
	Declare Main()
	End Main()
EndDeclareModule

Module Application
	Procedure Main()
		Debug "Start Application::Main()"
		; ...
		A::Init()
		B::Init()
		; ...
		ProcedureReturn #Null
	EndProcedure
EndModule

[Little John]

Just forget about UseModule(), and use the full name which starts with the respective module prefix instead.

Again, it defeats the purpose of having a module,

No, not at all.
The purpose of a module is to provide a separate name space, where the PB programmer can decide which identifiers (procedures, structures etc.) are "private" to the module, and which other identifiers can be accessed by code from outside the module. So for instance we can have "private" global variables in a module, which means that these variables are global only in that module, but are not known by the rest of the code. In contrast, when we have global variables in normal code, without using any module, these global variables are visible by the whole code. Well, I'm pretty sure these details are old news for you. But this is what the purpose of a module actually is.

as I could just prefix all names with the module name instead.

No.
It makes a great difference whether we have say Mod1::MyFunc() or Mod1_MyFunc().
In the first case, we have a module named Mod1, in which we can use all advantages that a module offers (private procedures etc., as I have outlined above very shortly). In the second case, we don't have a module.

When we write UseModule(Mod1) in the main code, then we can later save some typing, because we only have to write MyFunc() then. But that is not the purpose of modules. Modules were not introduced into PB in order to save typing.

Actually, UseModule() in the way it currently works partly defeats the purpose of having a module! Because the purpose of a module is to provide a separate name space. But in a code where it reads e.g.

Code: Select all

UseModule(Mod1)
UseModule(Mod2)
UseModule(Mod3)

the public parts of the name spaces of the 3 modules are not separate from each other anymore!

Well, because of this feature request it is obvious that you are also not happy with the way UseModule() currently works.

My point was and is, that the most simple and straightforward way to prevent problems IMO is just to do without UseModule(), and to use the module prefix (e.g. Mod1::) instead.
And on no account does doing without UseModule() defeat the purpose of having a module.
I hope I was able to explain the reasons why.

[StarBootics]

My point was and is, that the most simple and straightforward way to prevent problems IMO is just to do without UseModule(), and to use the module prefix (e.g. Mod1::) instead.
And on no account does doing without UseModule() defeat the purpose of having a module.

Exactly and to me the same thing apply to With/EndWith feature. I never use it and when I see a code using it and if the code worth it I'm taking time to remove any With/EndWith out of it.
I should really create a small tool program to do it for me.

Best regards
StarBootics