Modules
-
- Enthusiast
- Posts: 347
- Joined: Thu Jul 02, 2009 5:42 am
Modules
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
I looked at the samples but don't really understand what I would use them for?
Thanks
Re: Modules
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
Some hints here but I'm still not sure what it means...
http://www.purebasic.fr/english/viewtop ... 13&t=55071
MacBook Pro-M1 (2021), Sonoma 14.4.1, PB 6.10LTS M1
Re: Modules
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.
Old bugs good, new bugs bad! Updates are evil: might fix old bugs and introduce no new ones.
Re: Modules
(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.
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-M1 (2021), Sonoma 14.4.1, PB 6.10LTS M1
-
- Enthusiast
- Posts: 347
- Joined: Thu Jul 02, 2009 5:42 am
Re: Modules
Now I am even more confusedts-soft wrote:http://en.wikipedia.org/wiki/Modular_programming
Re: Modules
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:
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:
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.
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()
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()
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
Re: Modules
It's because a single colon denotes a statement separator.fsw wrote:Why do we have two colons?
Wouldn't one suffice?
Re: Modules
Oh yeah, that's right - I never use it thougheesau wrote:It's because a single colon denotes a statement separator.fsw wrote:Why do we have two colons?
Wouldn't one suffice?
(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
I am to provide the public with beneficial shocks.
Alfred Hitshock
Re: Modules
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:
ThingB.pb:
Main file:
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:
ThingA.pb:
ThingB.pb:
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.
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
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
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()
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
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
Code: Select all
DeclareModule ThingB
Declare DoThingB()
EndDeclareModule
Module ThingB
UseModule Common
Procedure DoThingB()
ReadConfiguration()
; ...
EndProcedure
EndModule
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
-
- Addict
- Posts: 4527
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: Modules
I appreciate this new Module feature very much, and I am really thankful that it is not specific to Mac OSX.
Re: Modules
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.
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
Re: Modules
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.
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
Re: Modules
I can confirm than the single pass compiler has nothing to do with the current module implementation.
Re: Modules
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.
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
Re: Modules
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.