ts-soft wrote:the conflict is inside the module. I can use all native command, so it conflicts with your names!
Oh well, thanks ts-soft! So this is a general design flaw.
We can create modules now. We use modules to prevent naming conflicts. And then,
if new commands are added to PB later (in 2 or 5 years), it is possible a new command name
conflicts with a name in my module. Boom! Now I have to change my module names and all
sources that used that specific module, while modules are there to prevent naming conflicts.
Let's say I create a module for animated Sprite handling, and it contains procedures like
LoadAnimSprite() and DisplayAnimSprite(), etc. Now 3 years later PB adds LoadAnimSprite() or DisplayAnimSprite()
to it's command set, and my module does not work anymore because PB commands stay over my commands.
This could happen with any procedure name we use in our modules, if a PB command with the same name
gets added later on...
How could that be changed? I think all PB commands could be moved to it's own (virtual) namespace/module.
Maybe call it "System::" or "PB::" or "Global::". This namespace is included by default, so we are able
to use all commands as before, without the module/namespace specifier.
If a name conflict appears, the programmer can solve it by writing the full name. So "PB::SetGadgetData" / "Global::SetGadgetData" / "System::SetGadgetData"
and my own "GadgetHelper::SetGadgetData" could coexist, if we use the full qualified name.
So if a name conflict error comes up, the compiler displays an error message about the name conflict.
We add the module/namespace name in front of the command where the conflict was, and PB knows now
the fully qualified name. Next compile does not show an error anymore.
Disallowing many hundred names by default, because a PB command has the same name, is somehow
degrading the usefulness of modules for preventing name conflicts.
Another example and possibility:
Code: Select all
DeclareModule GadgetHelper
EnableExplicit
Declare GadgetHelper::GetGadgetData(gadget, index=0)
Declare GadgetHelper::SetGadgetData(gadget, value, index=0)
EndDeclareModule
Module GadgetHelper
Global NewMap gadgetData.i()
Procedure GadgetHelper::GetGadgetData(gadget, index=0)
ProcedureReturn gadgetData(Str(gadget)+":"+Str(index))
EndProcedure
Procedure GadgetHelper::SetGadgetData(gadget, value, index=0)
gadgetData(Str(gadget)+":"+Str(index)) = value
EndProcedure
EndModule
GadgetHelper::SetGadgetData(1, 12)
GadgetHelper::SetGadgetData(2, 30)
Debug GadgetHelper::GetGadgetData(1)
Debug GadgetHelper::GetGadgetData(2)
For index = 1 To 10
GadgetHelper::SetGadgetData(1, index+100, index)
Next
For index = 1 To 10
Debug GadgetHelper::GetGadgetData(1, index)
Next
The full module/namespace name is added to 'Declare' and 'Procedure' here. Just something more to type (or copy/paste),
and PB now knows the full qualified name. As long as we don't use UseModule, there should be no naming conflict in this code.
Hope the developers can add something, anything, to work around this (in my opinion serious) naming problem.
