Modules
Re: Modules
Of course I appreciate the evolution. But, retyping anything allows for human error and lost time debugging.
To use a module element I am already starting in the hole with '::' everywhere vs 'xxx_' from includefiles.
I will study it more, but my initial reaction is includefiles are swifter and less wordy.
Thanks for the discussion and v5.2
To use a module element I am already starting in the hole with '::' everywhere vs 'xxx_' from includefiles.
I will study it more, but my initial reaction is includefiles are swifter and less wordy.
Thanks for the discussion and v5.2
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Modules
All this examples are very small and you can look at them in one screen. There is the little problem for me if modules are large, and you divide them in many files as it's inevitable, there is no way to see they are part of a module by just looking at a single file.
It's not a big thing, you can add a remark at the top, still ... it isn't what you would expect I think.
Anyway I don't want to nitpick, it's all already quite nice considering they were added on top of the "old" PB.
Don't know if I'll ever use them in their current form but that's another story. Let's say they didn't win me over for now
It's not a big thing, you can add a remark at the top, still ... it isn't what you would expect I think.
Anyway I don't want to nitpick, it's all already quite nice considering they were added on top of the "old" PB.
Don't know if I'll ever use them in their current form but that's another story. Let's say they didn't win me over for now
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: Modules
I don't see where it's "inevitable". Java for example force you to use the same filename for your class, so you have to put the whole code of your class inside one file. It forces to avoid spaghetti code and split it correctly. It has been widely adopted by the industry since a while, nothing new here so I don't see why PB should "innovate" in this domain.
ps: btw, there is no "old" compiler, as there is no "new" compiler
ps: btw, there is no "old" compiler, as there is no "new" compiler
Re: Modules
If a "class" gets to big, should I call it a "school"
I prefer modules and/or classes to be tight and small.
I cringe at the thought of a multi-file class or module?
I prefer modules and/or classes to be tight and small.
I cringe at the thought of a multi-file class or module?
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Modules
Inevitable maybe it's too strong. Even if I believe you can reach the point.Fred wrote:I don't see where it's "inevitable".
I'll change it to "preferable".
It's preferable to have a gigantic module split in many files to work on the single one you need at a certain moment, instead of having a single file loaded in the ide. I saw many times the ide slow down when working on a file too big, for example. That's just one of the reasons. Another can be I don't need to scroll and endless listing when the section I need to work on is 5% of that.
If I'm not mistaken namespaces (modules's cousins ok... not the same thing) available in many languages can be split on multiple files, simply repeating the namespace declaration in each one. That's something I would use.Fred wrote: It has been widely adopted by the industry since a while, nothing new here so I don't see why PB should "innovate" in this domain.
OK. Just to be clear it wasn't intended in a diminishing way. With old I just meant "the pb compiler has it was before, with no idea of the concept of modules inside it and not built with them in mind".Fred wrote: ps: btw, there is no "old" compiler, as there is no "new" compiler
The fact you are still able to expand it adding new feature at the language level go to your merit.
Obviously you can look at it from different angles, this was a kind of compliment.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: Modules
@freakfreak wrote: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...
Thank you for the in-depth explanation.
What some users (me included) thought of it at first sight was it to be some sort of "poor man's" oop thingy. But it's not.
Personally I hoped it would be the same/similar thing go[lang] has; not beeing an oop language they managed to add object capabilities into a non oop language. IMHO it's even superior than "real" oop languages.
Maybe in the future Modules can be even more powerful if they could be assigned to a receiver (user defined type) like go[lang] does.
Please do not be discouraged with all the babbling.
Take care.
I am to provide the public with beneficial shocks.
Alfred Hitshock
Re: Modules
Just finished to change a GUI library of mine from "normal" to Module.
It's a fairly easy thing to do.
It looks like Modules can be separated into several files if it's done like that:
Just make sure that all procedures from all the files are declared inside the DeclareModule section.
The only "trouble" I had so far is that macros need to stay outside of module declarations.
(otherwise my example app crashes after start...)
It's a fairly easy thing to do.
It looks like Modules can be separated into several files if it's done like that:
Code: Select all
; THIS IS THE MAIN LIBRARY FILE
;
DeclareModule
Structure Banana
TastesGood.l
EndStructure
Declare ProcFromFile1()
Declare ProcFromFile2()
Declare ProcFromFile3()
EndDeclareModule
Module myStuff
Structure myPrivateBanana
TastesGoodToo.l
EndStructure
; some private "global" vars...
global huh.l
global IfYouSaySo.s
XIncludeFile "File1.pbi"
XIncludeFile "File2.pbi"
XIncludeFile "File3.pbi"
EndModule
The only "trouble" I had so far is that macros need to stay outside of module declarations.
(otherwise my example app crashes after start...)
I am to provide the public with beneficial shocks.
Alfred Hitshock
Re: Modules
Sure, using includes to split them is not a problem.fsw wrote: It looks like Modules can be separated into several files if it's done like that:
I was just saying if you open an include and look at it later on, there is nothing to suggest it's part of a module.
You can't repeat Module myStuff / EndModule inside each include and have all the pieces merged together by the compiler.
Again, not saying it's something vital, only that having the possibility to do so I would do it to make it clearer.
I didn't experiment with macros + modules yet.fsw wrote: The only "trouble" I had so far is that macros need to stay outside of module declarations.
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
Re: Modules
Understood.
IMHO one of the strength of Modules seems to be that no private parts can be accessed.
So no need for "__This_Is_My_Very_Private_Really_Exclusive_Thing__" variables/structure/procedure names.
IMHO one of the strength of Modules seems to be that no private parts can be accessed.
So no need for "__This_Is_My_Very_Private_Really_Exclusive_Thing__" variables/structure/procedure names.
I am to provide the public with beneficial shocks.
Alfred Hitshock
Re: Modules
That's the main idea behing module.
Re: Modules
Fred,
was browsing through the help file to see if it's updated for 5.2 and saw that there is a:
(never used it myself...)
IMHO either the "music module" or the "new module" needs to be renamed.
Don't you think?
Otherwise we will have:
was browsing through the help file to see if it's updated for 5.2 and saw that there is a:
section, but it talks about music modules.PureBasic - Module
(never used it myself...)
IMHO either the "music module" or the "new module" needs to be renamed.
Don't you think?
Otherwise we will have:
Especially FreeModule or LoadModule might be used for the wrong thing.DeclareModule
EndDeclareModule
Module
EndModule
UseModule
UnuseModule
CatchModule
FreeModule
GetModulePosition
GetModuleRow
IsModule
LoadModule
ModuleVolume
PlayModule
SetModulePosition
StopModule
Last edited by fsw on Sat Jun 29, 2013 12:49 am, edited 1 time in total.
I am to provide the public with beneficial shocks.
Alfred Hitshock
Re: Modules
Go[lang] uses "package".
In PureBasic terms it would be:
Speaking of package, in go[lang] each package is in one or more files.
Each file starts with:
but there is no endpackage needed.
Actually each go file starts with package; if it's a normal app the package name is [mandatory]:
The nice thing about it is that each file tells you to which package it belongs.
Only main packages are [automatically] compiled to executables.
Non main packages are [automatically] compiled to static libraries
Ah, [programming] life can be so easy
In PureBasic terms it would be:
Code: Select all
DeclarePackage
EndDeclarePackage
Package
EndPackage
UsePackage
UnusePackage
Each file starts with:
Code: Select all
package myStuff
Actually each go file starts with package; if it's a normal app the package name is [mandatory]:
Code: Select all
package main
Only main packages are [automatically] compiled to executables.
Non main packages are [automatically] compiled to static libraries
Ah, [programming] life can be so easy
I am to provide the public with beneficial shocks.
Alfred Hitshock
-
- Addict
- Posts: 4527
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: Modules
Could you post a short snippet that demonstrates the issue?fsw wrote:The only "trouble" I had so far is that macros need to stay outside of module declarations.
(otherwise my example app crashes after start...)
There was a problem with Modules and Macros in PB 5.20 beta 2, which has been fixed in beta 3.
Is this the same problem which you encountered?
Re: Modules
Sorry Little John, I totally missed your question.
It was my own stupidity
While changing the code to use the new Module function I moved the macro to the top of the code (even before other include files are called).
The procedure that I was calling inside the macro was calling itself internally (because of the active macro) and a stack overflow was happening.
There are two solutions for this:
1) Call UndefineMacro inside the procedure; do my thing; and then redefine it again
2) Move the macro to the bottom of the code
I went with the second solution.
Sorry for the confusion.
It was my own stupidity
While changing the code to use the new Module function I moved the macro to the top of the code (even before other include files are called).
The procedure that I was calling inside the macro was calling itself internally (because of the active macro) and a stack overflow was happening.
There are two solutions for this:
1) Call UndefineMacro inside the procedure; do my thing; and then redefine it again
2) Move the macro to the bottom of the code
I went with the second solution.
Sorry for the confusion.
I am to provide the public with beneficial shocks.
Alfred Hitshock