Still super frustrated with how useless modules are

[Mistrel]

I tried coming back to PureBasic this week after leaving it sit for a couple of months. My coding style is very heavily influenced by self documenting code and strong encapsulation. I became exceptionally frustrated after taking a deep dive into the viability of using PureBasic for a particular use case and came away very bitter.

I wrote a lot about what I had difficulty with before and made several proposals on the feature request board.

After firing up PureBasic again this past week I tried to approach things as Fred had suggested:

viewtopic.php?p=524913#p524913

The proper way to this is to use a 'Common' or 'Global' Module and use UseModule in module which needs it:

Code: Select all

DeclareModule Stuff_I_Need
  Structure SomeStruct
    a.i
    b.i
    c.i
  EndStructure
EndDeclareModule

Module Stuff_I_Need
EndModule

DeclareModule SomeModule
  UseModule Stuff_I_Need
  Define a.SomeStruct
EndDeclareModule

Module SomeModule
EndModule

I won't reiterate the major problems faced by this approach but decided to give it a try with a new project. Then I realized that you can't nest modules.

There seems to be a strong misconception that modules are like namespaces in other languages and the documentation even reflects this thought. But every time I try to use them as such I quickly realize that this is simply not the case.

All modules seem to do is shift scope up from global into modules and no further. Therefore if you decide to write an entire application with an emphasis on modularizing everything, it effectively becomes the same thing, just shifted up one scope with a tremendous amount of additional verbosity.

I want to use PureBasic more often. I really, really do. But it's just so painful to be constantly reminded of so many limitations like this which tarnish an otherwise beautiful language.

[mk-soft]

I don't know what the problem is.
The use of modules (namespaces as you can inpret it) works as described.

There is a bit more paperwork in the declaration but you have a better separation of the names of variables and procedures.

I like working with modules very much...

You can also do strange things with modules.

Code: Select all

DeclareModule Public
  
  Structure udtPositions
    x.i
    y.i
    z.i
  EndStructure
  
  Declare.s Position(*data.udtPositions)
  Declare CopyPosition(*Source.udtPositions, *dest.udtPositions)
  
EndDeclareModule

Module Public
  
  Procedure.s Position(*data.udtPositions)
    ProcedureReturn "X="+*data\x+"/Y="+*data\y+"/Z="+*data\z + ": "
  EndProcedure
  
  Procedure CopyPosition(*Source.udtPositions, *dest.udtPositions)
    CopyStructure(*Source, *dest, udtPositions)
  EndProcedure
  
EndModule

DeclareModule Foo1
  Structure udtPropertyValue Extends Public::udtPositions
    Value.s
  EndStructure
  
  Property.udtPropertyValue
  
EndDeclareModule

Module Foo1
EndModule

DeclareModule Foo2
  Structure udtPropertyValue Extends Public::udtPositions
    Value.i
  EndStructure
  
  Property.udtPropertyValue
  
EndDeclareModule

Module Foo2
EndModule

foo1::Property\x = 100
foo1::Property\y = 200
foo1::Property\z = 300
foo1::Property\Value = "Hello"

Public::CopyPosition(Foo1::Property, Foo2::Property)
foo2::Property\Value = -999


Debug Public::Position(foo1::Property) + foo1::Property\Value
Debug Public::Position(foo2::Property) + foo2::Property\Value

[Mistrel]

The use of modules (namespaces as you can inpret it) works as described.

They work exactly as described because they describe their implementation.

The manual states:

In some other programming languages, modules are known as 'namespaces'.

Namespaces are extremely powerful tools for managing scope through hierarchy and inheritance, with verbosity further clarified through aliases and even further in combinations with macros. PureBasic fails on all of these counts.

The "scope" provided by namespaces is extremely limited and only provides a single layer above global scope. Its scope is also completely isolated and requires a tremendous amount of code duplication to work around this issue. The only way to take full advantage of modules as implemented is to have everything in your program a module somewhere. But now that you've abandoned global scope, you've just traded one scope for another with very little tangible benefit.

See here example code.

[skywalk]

Mistrel, I've done quite well without modules using "xxx_" lib prefixing.
No ::'s or Macro conflicts and I can access my shared globals without re-re-including them.
Let's have more power and targets before syntax sugar!

[RobertSF]

I tried coming back to PureBasic this week after leaving it sit for a couple of months. My coding style is very heavily influenced by self documenting code and strong encapsulation. I became exceptionally frustrated after taking a deep dive into the viability of using PureBasic for a particular use case and came away very bitter.

Yeah, I know the feeling. I'm a fairly new user. Downloaded the demo about six months ago and purchased a license just a few weeks later. Then I realized PureBasic's limitations (for me, in particular, the form designer), but when I went back to Visual Studio/VB.Net, I missed the simple power of PureBasic. In short, there's just no perfect language.

I've decided to use PureBasic for small "helper" applications that are very useful around the office and which I can develop in a day or two. It's perfect for that.

[Mistrel]

Mistrel, I've done quite well without modules using "xxx_" lib prefixing.
No ::'s or Macro conflicts and I can access my shared globals without re-re-including them.
Let's have more power and targets before syntax sugar!

That's what I've been doing for years. It's a real shame to see modules gone to waste.

[Little John]

... how useless modules are

People have contributed many modules here to the "Tricks 'n' Tips" section and to the new code archive. They will be happy to "learn" now that all their modules are useless ...

Its scope is also completely isolated and requires a tremendous amount of code duplication to work around this issue.

No, not necessarily. I have a lot of modules in my private source code library, and there is no duplicate code at all.

The only way to take full advantage of modules as implemented is to have everything in your program a module somewhere.

False.

[mk-soft]

The point is to encapsulate procedures. Even if they execute the same functions. Thus these encapsulated procedures are available several times.
If later it should show up that in a module this procedure must be changed in a separate case, this can be adapted without influence on the other procedures.

[Env]

I think a correction needs to be made here..

Less, 'how useless modules are', more frustrated with the fact you haven't found a use for them yet?

Modules are brilliant for modular programming - it's nice being able to hide all the spaghetti of a solution in a module exposing only stuff you want to be accessed by elsewhere in the project to prevent conflict and general mess

[Josh]

I think you have to distinguish between two kinds of operations:

• When I write a bigger program, I always split it into different includefiles. Procedures, global variables etc. then always have a prefix in the form XXX_. This works fine, but has the disadvantage that single variables, which are used more or less in almost every line of code, inflate the code and make it harder to read. Here I hoped that this could be improved with modules and failed miserably several times. If IncludeA accesses to IncludeB and IncludeB accesses to IncludeC and IncludeC accesses to IncludeA, I don't find a sensible way with modules.
• On the other hand, I have some ready-made Includefiles that could only be accessed by read-only. Here modules are a unique help. You can see that in the many Includefiles that are offered here in the forum.

[kpeters58]

When I write a bigger program, I always split it into different includefiles. Procedures, global variables etc. then always have a prefix in the form XXX_. This works fine, but has the disadvantage that single variables, which are used more or less in almost every line of code, inflate the code and make it harder to read. Here I hoped that this could be improved with modules and failed miserably several times. If IncludeA accesses to IncludeB and IncludeB accesses to IncludeC and IncludeC accesses to IncludeA, I don't find a sensible way with modules.

Josh, the circular references that seem to frustrate you can easily be resolved by splitting your include files (and the modules inside) into one file containing just the DeclareModule part and a second one containing just the Module - Endmodule piece.

[#NULL]

When I write a bigger program, I always split it into different includefiles. Procedures, global variables etc. then always have a prefix in the form XXX_. This works fine, but has the disadvantage that single variables, which are used more or less in almost every line of code, inflate the code and make it harder to read. Here I hoped that this could be improved with modules and failed miserably several times. If IncludeA accesses to IncludeB and IncludeB accesses to IncludeC and IncludeC accesses to IncludeA, I don't find a sensible way with modules.

Josh, the circular references that seem to frustrate you can easily be resolved by splitting your include files (and the modules inside) into one file containing just the DeclareModule part and a second one containing just the Module - Endmodule piece.

IIRC I had problems even with that (like using header files) if the headers themself are circular dependent.

[skywalk]

I think you have to distinguish between two kinds of operations:

• [A] When I write a bigger program, I always split it into different includefiles. Procedures, global variables etc. then always have a prefix in the form XXX_. This works fine, but has the disadvantage that single variables, which are used more or less in almost every line of code, inflate the code and make it harder to read. Here I hoped that this could be improved with modules and failed miserably several times. If IncludeA accesses to IncludeB and IncludeB accesses to IncludeC and IncludeC accesses to IncludeA, I don't find a sensible way with modules.
  On the other hand, I have some ready-made Includefiles that could only be accessed by read-only. Here modules are a unique help. You can see that in the many Includefiles that are offered here in the forum.

Life is so much easier writing all code in option A. And "XXX_Var" is most often shorter than "Modulename::Var". In the end, I want amalgamated code that I can rapidly debug and not worry about a plague of module syntax errors.

Splitting Modules into 2 include files is just wrong and defeats the purpose of aiding the developer encapsulate code.

Stepping off soapbox now...

[Dude]

Life is so much easier writing all code in option A

Agreed. I haven't made any modules myself, although I do use one Registry module written by HeX0R.

I did download some evaluation code, but rather than make it a module, I just searched/replaced all its variables to have a leading "eval_" in the names, so I know all its variables won't clash with anything else in my source. Just seems easier that way.

[collectordave]

Newish to PB myself long term VB user.

Now I have the hang of modiles (tearing hair out at first) I find them great.

Just finishing a programme of over 60,000 lines all modularised and no bother.

The first thing I do is have a global module called App then include this on almost the first line of my main prog then it is available in every module included after giving me what I call true global scope for the variables I need. They also allow me to create modal dialogs of any complexity with no bother.

Fully recommend modules.

CD