Modules

[skywalk]

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

[luis]

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

[Fred]

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

[skywalk]

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?

[luis]

I don't see where it's "inevitable".

Inevitable maybe it's too strong. Even if I believe you can reach the point.
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.

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.

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.

ps: btw, there is no "old" compiler, as there is no "new" compiler

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".
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.

[fsw]

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...

@freak
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.

[fsw]

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:

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

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...)

[luis]

It looks like Modules can be separated into several files if it's done like that:

Sure, using includes to split them is not a problem.
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.

The only "trouble" I had so far is that macros need to stay outside of module declarations.

I didn't experiment with macros + modules yet.

[fsw]

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.

[Fred]

That's the main idea behing module.

[fsw]

Fred,
was browsing through the help file to see if it's updated for 5.2 and saw that there is a:

PureBasic - Module

section, but it talks about music modules.
(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:

DeclareModule
EndDeclareModule
Module
EndModule
UseModule
UnuseModule
CatchModule
FreeModule
GetModulePosition
GetModuleRow
IsModule
LoadModule
ModuleVolume
PlayModule
SetModulePosition
StopModule

Especially FreeModule or LoadModule might be used for the wrong thing.

[luis]

Good catch

[fsw]

Go[lang] uses "package".

In PureBasic terms it would be:

Code: Select all

DeclarePackage
EndDeclarePackage
Package
EndPackage
UsePackage
UnusePackage

Speaking of package, in go[lang] each package is in one or more files.
Each file starts with:

Code: Select all

package myStuff

but there is no endpackage needed.

Actually each go file starts with package; if it's a normal app the package name is [mandatory]:

Code: Select all

package main

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

[Little John]

The only "trouble" I had so far is that macros need to stay outside of module declarations.
(otherwise my example app crashes after start...)

Could you post a short snippet that demonstrates the issue?
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?

[fsw]

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.