Modules

[spacebuddy]

Can someone explain to me what this new features is Modules?

I looked at the samples but don't really understand what I would use them for?

Thanks

[WilliamL]

This is something new. I suppose the Help file will explain some of it. I'd like a simple explanation too...

Some hints here but I'm still not sure what it means...

http://www.purebasic.fr/english/viewtop ... 13&t=55071

[ts-soft]

http://en.wikipedia.org/wiki/Modular_programming

[WilliamL]

(wikipedia) wow, can it be explained any more obtusely!?

Sounds like a Procedure but there must be more to it.. so we'll see as examples appear.

An explanation of the command set will help also.. when the 'Help' file is updated.

[spacebuddy]

http://en.wikipedia.org/wiki/Modular_programming

Now I am even more confused

[fsw]

I'm in the similar boat

The problem I have is to visualize how to use this facility.
The provided examples in this forum do not really help because the usage of the module in these examples are theoretical in nature and can't be projected (or made beneficial to use) in a real life situation. (well at least I can't see it - maybe you can...)

If the Modules could be used as types (hello go[lang] ) then it would make sense:

Code: Select all

; pretend Vehicle is the name of the module...
Global test.Vehicle
 test::NewAuto(77)
 test::NewBoat()

Why do we have two colons?
Wouldn't one suffice?
Or why not allow the backslash?

Anyhow, what's also missing is the possibility for an alias, this way collisions could be easily avoided:

Code: Select all

ImportModule hisMath "libs\ts-soft\super-cool-math" 
ImportModule myMath "libs\my-stuff\crappy-way-of-doing-things"

define his.hisMath
define my.myMath

;....
debug his:Py()
debug my:Py()

For now the module implementation adds only more typing
Really hope that someone explains this module stuff better, with real life examples that show the benefit.

[eesau]

Why do we have two colons?
Wouldn't one suffice?

It's because a single colon denotes a statement separator.

[fsw]

Why do we have two colons?
Wouldn't one suffice?

It's because a single colon denotes a statement separator.

Oh yeah, that's right - I never use it though
(it's a BASIC thing...)

Actually professional programmers are discouraged to place 2 statements on one line.
(the programming language doesn't matter)
Especially when several programmers need to share code.
They are encouraged to use the free space for additional documentation

[freak]

Simply put: Modules allow the separation of the code into parts that are isolated from each other. There is no risk of things like global variables or procedure names conflicting with other code parts. Only the code of a module defined in the "DeclareModule" block is accessible from the outside. This allows to break down a project into smaller/simpler parts that each can be coded separately without them interfering with each other.

Example:
Lets say the program has two major areas: To do thing A and to do thing B. The program could be split like this:

ThingA.pb:

Code: Select all

DeclareModule ThingA

  ; This is the only procedure callable from the outside
  Declare DoThingA(foo, bar)

EndDeclareModule


Module ThingA

  ; Here we can use simple names without fear of a name collision with another
  ; module. Without Modules, these would have to be called "ThingA_x" to separate
  ; them similar names in the ThingB code.
  Global x = 1, y = 2

  ; This procedure is only visible in here, so again, we can use any name we want
  ; without a collision with other code
  Procedure Calculate()
    ProcedureReturn 42
  EndProcedure 

  ; this can be called from the outside
  Procedure DoThingA(foo, bar)    
    x = Calculate() + y
    Debug x
  EndProcedure
  

EndModule

ThingB.pb:

Code: Select all

DeclareModule ThingB

  ; visible from the outside
  Declare DoThingB()
 
EndDeclareModule

Module ThingB

  ; here, the same names are used as in the ThingA module, but no problem.
  ; The global variable here is not the same as the one in ThingA.
  Global y
  
  Procedure Calculate()
    ProcedureReturn 21
  EndProcedure 
  
  Procedure DoThingB()
    y = Calculate()
    Debug y
  EndProcedure  
  
EndModule

Main file:

Code: Select all

XIncludeFile "ThingA.pb"
XIncludeFile "ThingB.pb"

; open the needed modules
UseModule ThingA
UseModule ThingB

; somewhere in the main code, call the modules
; ...
DoThingA(1, 2)

;.. and later...
DoThingB()

Whether you want to access the public parts of the modules using the full names i.e. "ThingA::DoThingA()" and "ThingB::DoThingB()" or open the modules as I did above is just a matter of style. The important benefit of the modules is inside the code for each: They are totally separated from each other. Each can be written without having to look at the other one to avoid conflicts.

Now lets say there is code that they should share. Simple: Put that in its own module that both can access:



Common.pb:

Code: Select all

DeclareModule Common
  
  ; some shared constants
  #SomeConstant = 1
  #OtherConstant = 25
  
  ; some shared code
  Declare ReadConfiguration()

EndDeclareModule

Module Common

  ; the shared procedure
  Procedure ReadConfiguration()
  EndProcedure

EndModule

ThingA.pb:

Code: Select all

DeclareModule ThingA

  ; This is the only procedure callable from the outside
  Declare DoThingA(foo, bar)

EndDeclareModule


Module ThingA

  UseModule Common


  Procedure DoThingA(foo, bar)    
    
    ReadConfiguration()
    Debug #SomeConstant    
    
  EndProcedure
  

EndModule

ThingB.pb:

Code: Select all

DeclareModule ThingB

  Declare DoThingB()
 
EndDeclareModule

Module ThingB

  UseModule Common


  Procedure DoThingB()  
    ReadConfiguration()
    ; ...
  EndProcedure  
  
EndModule

This is the essence of modules: Each code part is separated, and interaction only happens at the boundaries defined in the DeclareModule block. You have to explicitly access another module either with the "UseModule" command or by using the full name like "Common::#SomeConstant".

This separation also helps to reuse code better. If i decide i want ThingA also in another program, i can just include the ThingA.pb with a minimal risk for name collisions: Only the module name itself and the DoThingA() procedure are accessible from the outside. So a module with a well written public interface (good names without much risk for collisions) can be easily reused in other programs even if the actual module code contains names that would otherwise collide with the names in the new program.

[Little John]

I appreciate this new Module feature very much, and I am really thankful that it is not specific to Mac OSX.

[skywalk]

Like many, I am encouraged with the new Module possibilities, but would the implementation have been far simpler if the compiler could make multiple passes?
What is the desire/requirement to remain a single pass anyway when modern processors are so fast?
I see too many declares required and I already employ a prefix naming to my includefiles(xxx_constants/xxx_strucs/xxx_procedures) so there are no conflicts.
I also like the module aliases to help reduce typing and readability.

[freak]

What does that have to do with anything?

The reason to have a module declaration block was a design decision, not one dictated by the compiler implementation.

[Fred]

I can confirm than the single pass compiler has nothing to do with the current module implementation.

[skywalk]

My gripe is the necessity to manage declarations that could be caught by the compiler.
I have (X)IncludeFile.
I expected IncludeModule.
And within a module, I could define Public and Private elements.
As it is now, I have lots more typing if I choose to use Modules instead of IncludeFiles with 'xxx_' prefixes.

[Fred]

I don't think it's much more typing, and you have a clear overview of what is public, which is definitely a strong point (basically only public produre needs to be declared twice (variables, array, list etc. doesn't need to be declared again in the module body). Indeed, nobody forces you to use the modules, everyone has to find its best interest.