Modules

[skywalk]

But my last project already showed me that with the course of the time the way one usually manages and structures his code in PureBasic is no solution for complex applications.

Facts and figures please...
I'm at 18k lines of code and not done yet.
The compiler cranks out in < 7 sec.
I have 9 include files and an ever growing CodeTool.exe assistant that automates my various whims that the IDE cannot...yet.

When/why does the code become unmanageable?

[Shield]

Well just look at how many PureBasic projects actually grew bigger than a few thousand lines
(while keeping in mind that 'lines' actually don't mean anything at all).
Unfortunately not many PB programs of that size are around. (At least I don't hear about such projects very often).

Of course it highly depends on the programmer and how well he manages structure his code.
Languages are just way easier and more comfortable to use if there are clear structures
and well separted code parts. Currently, we don't have that in PureBasic.

We have to prefix all of our functions to keep them somehow separated which just leads
to unncessary long and ugly function names (e.g. MyLib_DoSomething, MyLib_DoSomethingOther).

Not having and not getting OOP is one thing. But OOP actually isn't a requirement to efficiently manage
larger projects. It's the ability to structurize your code and separate parts from other parts.

Having modules makes it way easier to exchange and re-use code or even complete (library) projects.


You say PB needs 7 seconds to compile your 18k lines?
Well, that's one hell of a lot. It might seem to be fast, but you have to wait 7 seconds every time you
want to test your application. Now imagine your application gets really huge and say you're now
at 80k lines. Do you want to wait 40 seconds every time you changed one single line?
Imagine how painful it would be to debug an application that needs 40 seconds every time you change something.


That isn't a problem if there is a properly implemented module management.
If you change code inside a module, you'll have to recompile that. But other modules
won't be affected by that change, so there is no need for the compiler to go over it again.


Having simple modules or probably even complex namespaces would make development (even more in a community like this) way more effective.
And probably way more fun.


I've just written a small snipped how I think it would be perfect for PureBasic.
Not saying that it should be implemented that way, it's just my humble opionion on this topic:

Code: Select all

Namespace GameEngine\VideoDevice

	Private depth.i ; Variable is only known inside GameEngine\VideoDevice.

	Private Procedure.i CreateDirectXDevice(width.i, height.i, depth.i)
		; Use native DirectX functions here.
		; [...]
		Module\depth = depth
		ProcedureReturn #True
	EndProcedure
	
	Public Procedure.i CreateDevice(width.i, height.i, depth.i)
		; Create Video Device here.
		; [...]
		CreateDirectXDevice(width, height, depth)
		ProcedureReturn #True
	EndProcedure
	
	Public Procedure.i GetDepth()
		ProcedureReturn Module\depth
	EndProcedure
	
EndNamespace

And in the main code, it could be used like this:

Code: Select all

Using GameEngine
VideoDevice\CreateDevice(1920, 1080, 32)
Debug VideoDevice\GetDepth() ; Would return 32.

Or even like this if you're sure that you won't get any name conflicts:

Code: Select all

Using GameEngine
Using GameEngine\VideoDevice
CreateDevice(1920, 1080, 32)
Debug GetDepth() ; Would return 32.

Cheers.

[IceSoft]

I think modules are like the same as linking a static lib?

[X0r]

Of course it highly depends on the programmer and how well he manages structure his code.
Languages are just way easier and more comfortable to use if there are clear structures
and well separted code parts. Currently, we don't have that in PureBasic.

That's the point, skywalk. Sure it is still possible to manage large projects but it's very unflexible. Especially when you are working in a team.

Shield, your suggestion concerning the syntax looks good to me but I think the keyword Namespace would be irritating since modules are not just namespaces.

Here is my addition:
Nestes Modules:

Code: Select all

Module Engine

  Public Procedure Start(...)
  
  EndProcedure

  Public Module Particle
  
    Public Procedure Create(...)
    
    EndProcedure
  
  EndModule

EndModule

And here is how to use it:

Code: Select all

ImportModule Engine As ENG

ENG.Start(...)

ENG.Particle.Create(...)

or

Code: Select all

ImportModule Engine

UseModule Engine

Start(...)
Particle.Create(...)

This would be fuckin awesome.

I think modules are like the same as linking a static lib?

Not really, but they also could be used as static libs.

[Shield]

Shield, your suggestion concerning the syntax looks good to me but I think the keyword Namespace would be irritating since modules are not just namespaces.

Well, modules are basically libraries that stand on their own.
It's just a term used to describe a group of functions / classes etc.

But modules can also contain namespaces.
In my example, the first (or the outmost) namespace would define the module
that can be compiled separately. Let's not confuse that.


If you look at Java for example, we could consider packages as modules.
If you look at C#, a library project would be a module.


And that's something I'd like to see in PureBasic, too.
Of course it's also possible to split that up, so the first namespace GameEngine
would become "Module GameEngine" to make it clear.


Also another important point is, that you don't actually include modules in your code (unlike includes),
you just tell the compiler that you wan't to use that module.

[skywalk]

Well just look at how many PureBasic projects actually grew bigger than a few thousand lines
(while keeping in mind that 'lines' actually don't mean anything at all).
Unfortunately not many PB programs of that size are around. (At least I don't hear about such projects very often).

Since there is no line continuation character ...lines are lines.
True, the size of projects is not discussed often, which is why I asked about your problem?

Now imagine your application gets really huge and say you're now
at 80k lines. Do you want to wait 40 seconds every time you changed one single line?
Imagine how painful it would be to debug an application that needs 40 seconds every time you change something.

This was also true, but after Trond suggested not using projects in the IDE, I now cut out the offending procedure into a separate file, paste my XincludeFiles at the top and debug away! This is really fast.

So, if I am understanding correctly, your request for Modules is not a "must" have, but a "nice to" have.

What I want to know...if we get Public and Private Procedures(), will my executable be smaller or run faster as a result.

That would be cool.

[Shield]

True, the size of projects is not discussed often, which is why I asked about your problem?

Well, I don't measure the size of a program by counting its lines but by the overall functionality.
There are really not that many projects out there I'd put in the "Big" category.

However the PureBasic editor is one of the "Big" ones, for example.

So, if I am understanding correctly, your request for Modules is not a "must" have, but a "nice to" have.

Nothing beyond plain assembler is a "must have". All those additional features that high level programming languages offer
are "nice to have". And modules certainly are "nice to have".

What I want to know...if we get Public and Private Procedures(), will my executable be smaller or run faster as a result.

Neither of those changes. Modules at their basics represent just another (more advanced) way to structure programming code.
Depending on the implementation of Modules, there can be differences of course.
But if I can manage my source code better with those additional features,
I'd be more then willing to exchange some speed for better readability and maintainability.
You won't notice the difference anyway.

And still, if you really have to get out every single nanosecond, no one forces anybody to use those module features.

[X0r]

I am wondering when Fred will answer on this.

[Marlin]

Coud not resist jumping in (without really reading all that was written in this thread before, but)

What I want to know...if we get Public and Private Procedures(), will my executable be smaller or run faster as a result.

This seem improbable to me, as it looks like more overhead.
Bigger and slower seems more probable in this case,
if there is an impact on size or speed at all.

Procedures inside Structures could be helpfull to larger projects.
(At least a bit, but not limited to larger projects.)

[coldhands]

We need ways to create modules with well defined interfaces and "black boxed" interns. It is needed to make PureBasic usable for bigger software projects and I really hope we can see some progress on this soon, so I can use PureBasic more often for my work.

[buddymatkona]

I have complained about "missing" PB features too but if they do not get added, I just remind myself that all compilers do not have to be alike and PB is priced very reasonably. People who are considering an application that may run close to 100K lines should dust off their wallet and get industrial strength tools.

[ColeopterusMaximus]

+1 to this one.

[VoSs2o0o]

+1 for the module concept, or another solution for
better Code-Seperation in bigger Projects.

[luis]

Nice to see this 2005 request is always alive and vibrant
Well let's hope, even if I believe nothing of this magnitude has ever been implemented in PB since its inception.
I'm skeptic since it's not a library or a new command. It would be a major enhancement of the language with a lot of "scope" rules all pacifically coexistent.

[skywalk]

As a fallback, I would prefer to create a static lib from the IDE menu.