Allow a ImportModule ... As ..., or a RenameModule old, new

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
User avatar
Demivec
Addict
Addict
Posts: 4261
Joined: Mon Jul 25, 2005 3:51 pm
Location: Utah, USA

Allow a ImportModule ... As ..., or a RenameModule old, new

Post by Demivec »

I think it would be helpful to have a command to handle name clashes regard the names of modules. I suggest the command RenameModule oldname, newname.

When used this would require module 'oldname' be referred to only as 'newname'. This means oldname::x would become newname::x and UseModule oldname would be UseModule newname. This would allow dealing with the name clash at the point where the module's code is included and not in the code itself (in case it is used elsewhere).


The second case is allowing a module to use an alias. I suggest the command ImportModule original_name As alias_name. This would allow a module to be referenced by both new and old portions of a program. Old code (or interfacing) could interact with the the module as alias_name while newer code might interact with it by referring to it under its original_name (also accessing any additional features that were added).

In time, a better example may present itself after the use of modules has gained some traction in the toolbox of PureBasic programmers. In the meantime I cobbled together some code to try and illustrate some use for these commands.

The code is meant to be treated as showing the contents of 4 separate files, 3 of which contain modules. It is a contrived example. I am aware that their may be other solutions to this problem that can be accomplished with structuring the code in various ways. The code can't be run because the commands to do so aren't implemented yet :wink:. Even so, it would only draw a pattern on an image (but not display or save it).

Code: Select all

;file 1 "triangle.pbi"
DeclareModule triangle
  Global color = RGB(30, 255, 255)
  Declare draw(x, y, length) ;draws triangle with sides of (length) from top (centered) point (x, y)
EndDeclareModule

Module triangle
  Procedure draw(x, y, length) ;draws triangle with sides of (length) from top (centered) point (x, y)
    Protected height = length * Sin(30)
    Line(x, y, length / 2, height, color)                        ;right
    Line(x - (length / 2) - 1, y + height - 1, length, 1, color) ;bottom
    Line(x, y, -length / 2, height, color)                       ;left
  EndProcedure
EndModule

;=================================
;file 2 "box.pbi"
DeclareModule box
  Global color = RGB(255, 255, 30)
  Declare draw(x, y, length) ;draw box with sides of (length / 2) from top-left corner (x, y)
EndDeclareModule
  
Module box
  Procedure draw(x, y, length)  ;draw box with sides of (length / 2) from top-left corner (x, y)
    length / 2
    Line(x, y, 1, length, color)              ;left
    Line(x, y + length - 1, length, 1, color) ;bottom
    Line(x + length - 1, y, 1, length, color) ;right
    Line(x, y, length, 1, color)              ;top
  EndProcedure
EndModule

;=================================
;file 3 "my_box.pbi"  
DeclareModule box
  Global color = RGB(255, 30, 255)
  Declare draw(x, y, length) ;draw box with sides of (length) from top-left corner (x, y)
EndDeclareModule
  
Module box
  Procedure draw(x, y, length)  ;draw box with sides of (length) from top-left corner (x, y)
    Line(x, y, 1, length, color)              ;left
    Line(x, y + length - 1, length, 1, color) ;bottom
    Line(x + length - 1, y, 1, length, color) ;right
    Line(x, y, length, 1, color)              ;top
  EndProcedure
EndModule  

;=================================
;start of the main file, "main.pb"

;Normally select only one of the modules and change the line with "ImportModule ... As shape" to refer to it
Include "triangle.pbi"

ImportModule triangle As shape  ;Now the module is known as both 'triangle' and 'shape' going forward.
;
;Routines that are designed for a module named 'shape' will operate without further tailoring.
;     The alternative would be to edit the code each time the UseModule is used, or to replace the full
;module named (i.e. replace triangle::draw() with box::draw()) everywhere it is used.  Alternatively
;the module being added would have to be renamed so that it matches with the code that uses it.
;     If ImportModule ... As ... is used instead it would allow code to be tailored by swapping some modules
;in and out as long as their public members were the same.  This would allow the module name to carry
;some distinguising elements.

UseModule shape
Define i
CreateImage(1, 200, 200, 24, 0)
StartDrawing(ImageOutput(1))
  For i = 1 To 15
    draw(i * 10, i * 10, 40)
  Next
StopDrawing()

UnuseModule shape

;-----------------------------------------------
;Another issue, name clashes ...

;Include "box.pbi"
;;If both modules box and my_box were included we would need to rename one of them to avoid a name clash.
;RenameModule box, small_box ;Now the box module would be known only as small_box.
;Include "my_box.pbi"
I'm sure there will be opinions about whether this is a good idea or not. Please feel free to say what you like or hate about the idea and well see what becomes of it. :)
User avatar
luis
Addict
Addict
Posts: 3895
Joined: Wed Aug 31, 2005 11:09 pm
Location: Italy

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by luis »

Anything useful to avoid nameclashing is welcomed by me.
That said:

1) I think the problem can happen a lot more frequently with procedures than with modules.
The probability you have two modules with the same name is very low, unless you really choose an unwise name for the module.

To have a procedure named "LoadTexture()" in two different modules (Demivec3DEngine and LuisTextureCompressor) is something can happen a lot more easily.
If you followed the threads about modules you already know the answer from Freak to this problem would be "use well chosen names and if that's not enough use the full name qualifier for the rare cases when a clash happens".
I tend to agree because I don't see a better solution.

2) All this renaming and aliasing I think can be interpreted like a further cause of confusion, and I have the impression the developers tend to favor incremental enhancements to the language keeping the sophistication level in check (like the proposed Friends extension to modules, or even the long debated OOP) that can potentially create a "great divide" between the PB programmers base.
So more an addition is "fancy", not clear-cut, lower the probability of its implementation.

In the end: even not considering point 2, renaming and aliasing can be useful in case of module name clashing (extremely rare in my opinion) but not in case of procedure name clashing (a possible real problem instead without a magical solution beyond the use of full qualifiers).
"Have you tried turning it off and on again ?"
A little PureBasic review
User avatar
Demivec
Addict
Addict
Posts: 4261
Joined: Mon Jul 25, 2005 3:51 pm
Location: Utah, USA

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by Demivec »

luis wrote:1) I think the problem can happen a lot more frequently with procedures than with modules.
The probability you have two modules with the same name is very low, unless you really choose an unwise name for the module.

To have a procedure named "LoadTexture()" in two different modules (Demivec3DEngine and LuisTextureCompressor) is something can happen a lot more easily.
If you followed the threads about modules you already know the answer from Freak to this problem would be "use well chosen names and if that's not enough use the full name qualifier for the rare cases when a clash happens".
I tend to agree because I don't see a better solution.
To restate what you have said, you think the problems are more common with procedures than module names and that such a problem (with procedures) can be often solved by using fully qualified names.

I think that modules are useful because they help resolve name clashes that result from programs as they become larger (or even monstrous). They allow individuals or teams to work on a project without having to mitigate the finer name clashes from procedures names, structures, constants, or global variables. This being said, that means that in a large program it is possible to have a large number of modules which will result in the increased possibility of name clashes for the module names themselves.

My suggestions don't resolve the problems and side effects of 'UseModule'. They are really about changing/aliasing the qualified name.

luis wrote:2) All this renaming and aliasing I think can be interpreted like a further cause of confusion, and I have the impression the developers tend to favor incremental enhancements to the language keeping the sophistication level in check (like the proposed Friends extension to modules, or even the long debated OOP) that can potentially create a "great divide" between the PB programmers base.
So more an addition is "fancy", not clear-cut, lower the probability of its implementation.

In the end: even not considering point 2, renaming and aliasing can be useful in case of module name clashing (extremely rare in my opinion) but not in case of procedure name clashing (a possible real problem instead without a magical solution beyond the use of full qualifiers).
I think I agree with you here. In making my suggestions I have attempted to simplify things whenever possible and to look for what will have the most benefit while simultaneously being the least intrusive.
c4s
Addict
Addict
Posts: 1981
Joined: Thu Nov 01, 2007 5:37 pm
Location: Germany

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by c4s »

luis wrote:[...] To have a procedure named "LoadTexture()" in two different modules (Demivec3DEngine and LuisTextureCompressor) is something can happen a lot more easily.
If you followed the threads about modules you already know the answer from Freak to this problem would be "use well chosen names and if that's not enough use the full name qualifier for the rare cases when a clash happens".
I tend to agree because I don't see a better solution.
Demivec wrote:My suggestions don't resolve the problems and side effects of 'UseModule'. They are really about changing/aliasing the qualified name.
What do you think about automatic renaming?
I created a feature request for that and think that it could solve the problem in an easy way... or am I wrong about that?
If any of you native English speakers have any suggestions for the above text, please let me know (via PM). Thanks!
User avatar
Demivec
Addict
Addict
Posts: 4261
Joined: Mon Jul 25, 2005 3:51 pm
Location: Utah, USA

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by Demivec »

c4s wrote:What do you think about automatic renaming?
I created a feature request for that and think that it could solve the problem in an easy way... or am I wrong about that?
@c4s: Automatic renaming is more extensive than my suggestions but similar; it involves not changing the module name but instead changing the items one step below that, the procedures, constants, structures, global variables and variables local to the module (outside a procedure). Automatic naming seems complementary to what I suggested.

One feature of modules is that they limit these name clashes to just the public stuff in the module. I agree with luis that choosing suitable names for the public things helps. Aside from that though I think there will be a need to mitigate name clashes further. If only one method was allowed (or implemented) I would prefer renaming or aliasing of the module name, if more than one method was implemented I think automatic renaming would round out the choices. There may still be a better choice that includes them all.

I agree with luis,
luis wrote:Anything useful to avoid nameclashing is welcomed by me.
:)
BorisTheOld
Enthusiast
Enthusiast
Posts: 542
Joined: Tue Apr 24, 2012 5:08 pm
Location: Ontario, Canada

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by BorisTheOld »

luis wrote:All this renaming and aliasing I think can be interpreted like a further cause of confusion, and I have the impression the developers tend to favor incremental enhancements to the language keeping the sophistication level in check.....that can potentially create a "great divide" between the PB programmers base.
I agree.

In an attempt to simplify the coding process, all the recent requests for "improvements" to the new Module feature are guaranteed to make coding more complex and error prone. Its obvious that most of the requests are focused on one narrow issue, without understanding the true purpose or power of Modules, or how to accomplish the task using existing PB features.

There seems to be the idea, among some on this forum, that well structured programs and meaningful data names are a waste of programming effort. That planning ahead and typing a few extra characters wastes too much time. Such an approach may be adequate for small programs with a few hundred lines of code, but applications with thousands or millions of lines require a much higher level of organization.

We have a comprehensive set of rules for naming everything from applications down to temporary loop counters. We currently have about 20,000 named items. Each item has a unique name and purpose, and its properties and usage is always the same no matter where the item is used.

I'm not suggesting that everyone needs that level of organization. But some of the requests for Module improvements seem to be nothing more than ways to graft modules onto existing code, in the hope this will somehow create perfection and simplicity out of chaos.

To use modules, one needs to plan for their use. And if done properly there won't be any need for most of the requested "improvements".
For ten years Caesar ruled with an iron hand, then with a wooden foot, and finally with a piece of string.
~ Spike Milligan
c4s
Addict
Addict
Posts: 1981
Joined: Thu Nov 01, 2007 5:37 pm
Location: Germany

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by c4s »

@BorisTheOld
Seems that you're talking about me and my feature request. But why so indirectly?

Constructive critics are very welcome, but then I would prefer it if you would directly address me and/or the request. I still think that it's a valid and good solution for the stated problem. That's why I'm even more interested in other opinions and ways of handling it.
If any of you native English speakers have any suggestions for the above text, please let me know (via PM). Thanks!
BorisTheOld
Enthusiast
Enthusiast
Posts: 542
Joined: Tue Apr 24, 2012 5:08 pm
Location: Ontario, Canada

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by BorisTheOld »

c4s wrote:@BorisTheOld
Seems that you're talking about me and my feature request. But why so indirectly?
Not at all.

I was talking to the world at large about all the Module-related requests that have been made since Fred announced 5.20.

The whole point of having Modules is to encapsulate a number of related procedures, so that prefixes don't have to be attached to every procedure name or data name. Think of them as a source version of a dynamic library (.dll / .so) or class, with limited visibility to the outside world.

The intent of this sort of contruct is to limit access to the contents of the module, not make everything available, but without the name prefixes. If this were allowed, how can the compiler possibly know which procedures and data items I want to access.

All that's needed to access the contents of a module is to add the module name as a prefix to the reference. But this is no hardship, because access to the module will only be via a few procedures. Remember the .dll analogy? Used this way there can never be any name conflicts, except if module names are not unique. But if that's the case then change the names. After all, that's what one has to do if two different variables have the same name.

As soon as one starts thinking in terms of tunneling into the module to access the contents directly, then name conflicts will happen. It will be structured spaghetti code. As I said, modules are not intended to be used that way. If shared variables are needed, put them into a common module and access them using the fully modified name: ModuleName::DataName

In a well organized program, modules will bring structure and visibility, and will actually simplify the whole coding process. Most of the requested wishlist features aren't needed.
For ten years Caesar ruled with an iron hand, then with a wooden foot, and finally with a piece of string.
~ Spike Milligan
c4s
Addict
Addict
Posts: 1981
Joined: Thu Nov 01, 2007 5:37 pm
Location: Germany

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by c4s »

@BorisTheOld
Thanks for your detailed explanation. Makes me wonder if my requested feature is really as useful as I first thought, because honestly I didn't really play with PB's new module concept yet... Time will tell. ;)
If any of you native English speakers have any suggestions for the above text, please let me know (via PM). Thanks!
davido
Addict
Addict
Posts: 1890
Joined: Fri Nov 09, 2012 11:04 pm
Location: Uttoxeter, UK

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by davido »

@BorisTheOld,

Thank you for your explanation. :D
DE AA EB
freak
PureBasic Team
PureBasic Team
Posts: 5940
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Re: Allow a ImportModule ... As ..., or a RenameModule old,

Post by freak »

I too feel that some of the requests for more module features are a bit "premature" for lack of a better word. Especially the fear of frequent name conflicts is unfounded in my opinion. Its not a problem I often see in the use of other languages. My suggestion is to wait a bit and first write some real world code with the new modules and you too will see that these things are not really an issue.

Give it some time. You will learn to like the simplicity of it as it is now. We can always make it more complicated in a later version if needed :wink:
quidquid Latine dictum sit altum videtur
Post Reply