Remove name conflict check for modules and internal commands

[Danilo]

Code: Select all

DeclareModule GadgetHelper
    EnableExplicit
    Declare GetGadgetData(gadget, index=0)
    Declare SetGadgetData(gadget, value, index=0)
EndDeclareModule

Module GadgetHelper
    
    Global NewMap gadgetData.i()
    
    Procedure GetGadgetData(gadget, index=0)
        ProcedureReturn gadgetData(Str(gadget)+":"+Str(index))
    EndProcedure
    
    Procedure 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

This code should work, because there is no name conflict as long as we don't use UseModule.
Now we can't use any name in modules if there is already a PB command with this name.

Have to use GadgetHelper::GetGadgetData_() and GadgetHelper::SetGadgetData_().

[ts-soft]

There is a nameconflict with the native gadgetcommand GetGadgetData()

[Danilo]

There is a nameconflict with the native gadgetcommand GetGadgetData()

"GetGadgetData()" <> "GadgetHelper::GetGadgetData()"

There would only be a conflict if UseModule is used to import it into global namespace.
Without UseModule, there is no conflict.

[ts-soft]

the conflict is inside the module. I can use all native command, so it conflicts with your names!

[eesau]

The most annoying thing about this is that some native commands in PB are named in a way too general fashion: things like GetX(), GetY() etc. always clash for me.

[PMV]

Yep,

The most annoying thing about this is that some native commands in PB are named in a way too general fashion: things like GetX(), GetY() etc. always clash for me.

Especially for that ones, i was a little surprised, too.
I would wish to have that ones renamed to a little
longer more precise names.

MFG PMV

[Danilo]

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.

[BorisTheOld]

This request is just plain silly.

But it's particularly silly that programmers complain about the compiler when they use an existing reserved word for a variable or procedure name.

Life happens, so get over it and change your code.

It's what programmers do.

[PMV]

Not only programmers have wishes ... and i'm with Danilo here.
PB-Functions shouldn't collide with Modul-Functions, as long as
the full prefix is used.

MFG PMV

[PB]

I agree with Boris. If a new command conflicts with our own stuff,
we should rename our own stuff. I've had to do it before; I used to
have "list" as a variable name, but now I can't. I now call it "mylist"
instead. It's not a big deal for us to fix; just a search and replace on
whole words in our sources.

[Justin]

Use objects and intrfaces, problem solved.

[eesau]

I have to go with Danilo on this one, some resolution for naming conflicts with native functions would be nice.

[BorisTheOld]

I would guess that "PB", "Global", and "System" are all good names for PB users to give to their own global modules. So the programmers who didn't have a naming problem now have one, since the compiler will complain that "Global::ProcName" is not a valid PB command.

And what will those programmers have to do to fix the problem? That's right -- change their code.

Just change your code and stop wasting everyone's time.

[freak]

Replacing a builtin function is not a good idea. It will make your code less readable to yourself and others. That said, if you really want to, you can do it using macros.

[Danilo]

Just testing. Behavior is completely different for API commands. Tested with PB5.20 beta18, Windows and MacOSX.

Code: Select all

DeclareModule Application
    EnableExplicit
    Declare send_(value=0)
EndDeclareModule

Module Application

    Procedure send_(value=0)
        Debug #PB_Compiler_Module + "::" + #PB_Compiler_Procedure
        
        ; test name precedence for recursion
        If value = 12
            ;Application::send_()  ; call  Application::send_() explicitely
            send_()                ; calls Application::send_(), not API send_()
            ;System::send_()       ; should always call API and PB functions, it is one reserved namespace ;)
        EndIf
        Debug value
    EndProcedure
    
EndModule

Application::send_(12)

Delay(2000)

UseModule Application

send_() ; With UseModule it is Application::send_()
        ; API command is used without UseModule