Modules

Mac OSX specific forum
spacebuddy
Enthusiast
Enthusiast
Posts: 344
Joined: Thu Jul 02, 2009 5:42 am

Modules

Post by 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 :D
WilliamL
Addict
Addict
Posts: 1142
Joined: Mon Aug 04, 2008 10:56 pm
Location: Seattle, USA

Re: Modules

Post by 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
MacBook Pro-r, OSX 10.14.6 , PB 5.73LTS
User avatar
ts-soft
Always Here
Always Here
Posts: 5758
Joined: Thu Jun 24, 2004 2:44 pm
Location: Berlin - Germany

Re: Modules

Post by ts-soft »

PureBasic 5.73 | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Image
WilliamL
Addict
Addict
Posts: 1142
Joined: Mon Aug 04, 2008 10:56 pm
Location: Seattle, USA

Re: Modules

Post by 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.
MacBook Pro-r, OSX 10.14.6 , PB 5.73LTS
spacebuddy
Enthusiast
Enthusiast
Posts: 344
Joined: Thu Jul 02, 2009 5:42 am

Re: Modules

Post by spacebuddy »

Now I am even more confused :shock:
User avatar
fsw
Addict
Addict
Posts: 1489
Joined: Tue Apr 29, 2003 9:18 pm
Location: North by Northwest

Re: Modules

Post by 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] :P ) 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 :mrgreen:
Really hope that someone explains this module stuff better, with real life examples that show the benefit.

I am to provide the public with beneficial shocks.
Alfred Hitshock
eesau
Enthusiast
Enthusiast
Posts: 589
Joined: Fri Apr 27, 2007 12:38 pm
Location: Finland

Re: Modules

Post by eesau »

fsw wrote:Why do we have two colons?
Wouldn't one suffice?
It's because a single colon denotes a statement separator.
User avatar
fsw
Addict
Addict
Posts: 1489
Joined: Tue Apr 29, 2003 9:18 pm
Location: North by Northwest

Re: Modules

Post by fsw »

eesau wrote:
fsw wrote: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 :oops:
(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 :P

I am to provide the public with beneficial shocks.
Alfred Hitshock
freak
PureBasic Team
PureBasic Team
Posts: 5829
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Re: Modules

Post by 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.
quidquid Latine dictum sit altum videtur
Little John
Addict
Addict
Posts: 4000
Joined: Thu Jun 07, 2007 3:25 pm
Location: Berlin, Germany

Re: Modules

Post by Little John »

I appreciate this new Module feature very much, and I am really thankful that it is not specific to Mac OSX. :D
Please excuse my flawed English. My native language is PureBasic.
Search
RSBasic's backups
User avatar
skywalk
Addict
Addict
Posts: 3532
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Modules

Post by 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.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
freak
PureBasic Team
PureBasic Team
Posts: 5829
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Re: Modules

Post by 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.
quidquid Latine dictum sit altum videtur
Fred
Administrator
Administrator
Posts: 14351
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Re: Modules

Post by Fred »

I can confirm than the single pass compiler has nothing to do with the current module implementation.
User avatar
skywalk
Addict
Addict
Posts: 3532
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Modules

Post by 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.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Fred
Administrator
Administrator
Posts: 14351
Joined: Fri May 17, 2002 4:39 pm
Location: France
Contact:

Re: Modules

Post by 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.
Post Reply