Different way to split modules in multiple files

[luis]

Since modules implementation is still subject to little variations, would it be much difficult to make possible to do this:

Code: Select all

DeclareModule lib1
 Declare func1(par)
 Declare func2(par)
EndDeclareModule

Module lib1
 Procedure func1(par)
  Debug "lib1 func1:" + par  
 EndProcedure
EndModule

Module lib1
 Procedure func2(par)
  Debug "lib1 func2:" + par  
 EndProcedure
EndModule

UseModule lib1

func1(1)

func2(2)

instead of this ?

Code: Select all

DeclareModule lib1
 Declare func1(par)
 Declare func2(par)
EndDeclareModule

Module lib1
 Procedure func1(par)
  Debug "lib1 func1:" + par  
 EndProcedure
 
 Procedure func2(par)
  Debug "lib1 func2:" + par  
 EndProcedure
EndModule

UseModule lib1

func1(1)

func2(2)

I understand it's possible to make an include like this

Code: Select all

DeclareModule lib1
 Declare func1(par)
 Declare func2(par)
EndDeclareModule

Module lib1
 IncludeFile "module_piece_1.pb"
 IncludeFile "module_piece_2.pb"
EndModule
 

But inside each include it would not be clear that code is part of a module... since the keyword Module appear only once in the root include.

Would be nicer if I could do something like this:

Code: Select all

DeclareModule lib1
 Declare func1(par)
 Declare func2(par)
EndDeclareModule

IncludeFile "module_piece_1.pb"
IncludeFile "module_piece_2.pb"

and to have something like

Code: Select all

Module lib1
 ..code..
EndModule

inside each include.


Would it be problematic to permit to do so ?

[tored]

This is an excellent suggestion. As the module documentation says

In some other programming languages, modules are known as 'namespaces'.

In those languages it is quite common to split namespaces into multiple files but still have a namespace declaration in each file.

[jacdelad]

Hi luis,
why do you want to split a module at all?

As much as I understand enhancing a module could be a great idea, but the second include should also provide the respective DeclareModule-part for its functions. Or am I lost?

[tored]

Hi luis,
why do you want to split a module at all?

As much as I understand enhancing a module could be a great idea, but the second include should also provide the respective DeclareModule-part for its functions. Or am I lost?

For better organisation if the module becomes too big, assume you are writing a library for custom gadgets, all should be under the same module name however each gadget could be in a separate file to keep it tidy because each gadget does not share that much with each other except the module name.

DeclareModule could also be repeated multiple times for the same module name, however not as important as the Module declaration. Typically you have one one DeclareModule file, your module's external api and then a bunch of Module files that are internal and typically the user of the module does not need to bother to read them. Compare to C/C++ header file and multiple implementation files.

[luis]

Hi luis,
why do you want to split a module at all?

Hi, for the usual reasons; limit the size of files and maybe better organization (you can have a module with different sections doing different things, think of an engine with its sub-components, would be nice to split it without losing the identity of the module itself when looking at the single files). About the declares, I was ok with having them in one file, after all they are just the public interface of the module, shouldn't grow too big..

Anyway this was a very minor request, non very important.

The request is 10 years old and I made it only because modules were just appearing in PB 5.20, and because as tored mentioned there were already languages doing exactly that, nothing new to be invented. So I hoped that could have been implemented before the modules finalization.
There are bigger problems with modules than this insignificant thing, and those were also discussed at the time but nothing changed in the final implementation. They are mentioned even today from time to time to be honest but it's just beating a dead horse.

Anyway I stopped discussing about how the language could evolve and what should be nice to have a long time ago, now I still mention a bug if I found it but that's about it. I just use it as it is and deal with the good and the bad.

[jacdelad]

Thanks for explaining.

Luis, this is the first time I read something critical about PureBasic itself from you. I know there's loooooots of people here who know much more about programming than me, so I take most things the way they are (excluding bugs). If it hasn't happened, I'm sure Fred has his reasons. Also, let's not forget that other programming languages have big teams and PureBasic is maintained by almost a single person.