How will source files linked into more than one module?

[uwekel]

Hi,

i have a common source file with global stuff used by several projects. When playing around with the new module feature, i noticed that the source must be included in each module separately to gain access to the procedures. Now i have 2 questions:

1. Is there a way to access procedures which are outside of a module?
2. If the file is included two times as in the example below, will the code be linked twice and blow up the executables size?

Code: Select all

DeclareModule First
  Declare Init()
EndDeclareModule

Module First
  IncludeFile "../Common/Common.pb"
  Procedure Init()
    MyCommonProcedure()
  EndProcedure
EndModule

DeclareModule Second
  Declare Init()
EndDeclareModule

Module Second
  IncludeFile "../Common/Common.pb"
  Procedure Init()
    MyCommonProcedure()
  EndProcedure
EndModule

Best regards
Uwe

[idle]

you would have to wrap your common code in a module in this instance

Code: Select all

DeclareModule  Common 
    IncludeFile "../Common/CommonDeclares.pb"
EndDeclareModule 

Module Common 
    IncludeFile "../Common/CommonFunctions.pb"
EndModule 

DeclareModule First
  Declare Init()
EndDeclareModule

Module First
  Procedure Init()
   Common::MyCommonProcedure()
  EndProcedure
EndModule

DeclareModule Second
  Declare Init()
EndDeclareModule

Module Second
  Procedure Init()
  Common::MyCommonProcedure()
  EndProcedure
EndModule

[luis]

To answer your questions:

1. Is there a way to access procedures which are outside of a module?

No, not really*. You would need to be able to do this:

Code: Select all

::Procname()

And you can't -> http://www.purebasic.fr/english/viewtop ... =3&t=55252

2. If the file is included two times as in the example below, will the code be linked twice and blow up the executables size?

Yes. The modules are separated entities, if you write the same proc twice in two different modules, PB does not enter in the merit of this.
They are two different objects tied to different modules.

In your case to share common code between modules you have to define a third module and access it from the other two as shown by idle.


*about the "not really" above:

Code: Select all

DeclareModule x
  Declare Init(*fp)
  Declare CallOutSide(a,b)
EndDeclareModule

Module x
 Global *fp   
 
 Procedure Init(*addr)
  *fp = *addr
 EndProcedure
    
 Procedure CallOutSide(a, b)
   ProcedureReturn CallFunctionFast(*fp, a, b) ; you are calling a proc external to the module
 EndProcedure
EndModule



Procedure.i sum(a,b)    
 ProcedureReturn a + b  
EndProcedure


x::Init(@sum()) ; -> inform the module about its existence

Debug x::CallOutSide(10,20)  ; invoke a module's proc 

the same thing with prototypes

Code: Select all

DeclareModule x
  Declare Init(*fp)
  Declare CallOutSide(a,b)
EndDeclareModule

Module x
 Prototype.i Sum_OUT(a, b)
 Global Sum.Sum_OUT   
 
 Procedure Init(*addr)
  Sum = *addr
 EndProcedure
    
 Procedure CallOutSide (a, b)
  ProcedureReturn Sum(a, b)
 EndProcedure
EndModule



Procedure.i Sum(a,b)    
 ProcedureReturn a + b  
EndProcedure


x::Init(@Sum())

Debug x::CallOutSide(10,20)

[uwekel]

Thank you, idle and luis! I think wrapping the common stuff into an own module is a good and lightweight solution. But i am still hesitating wether or not to change everything into modules

[BorisTheOld]

Encapsulating functionality is the preferred coding strategy. Whether it's in the form of modules, dynamic libraries, namespaces, or classes, the benefits are the same. The main one being that the internal workings of the module are hidden from the rest of the application, thereby making maintenance easier and unwanted interactions less likely.

Although we are madly converting our applications to PureBasic, our production code is still in the form of PowerBasic DLL's. Some modules (DLL's) provide services for all applications, while others are specific to an application.

Our modules/classes typically range in size from about 500 to 200,000 lines of code.

[uwekel]

Encapsulating functionality is the preferred coding strategy. Whether it's in the form of modules, dynamic libraries, namespaces, or classes, the benefits are the same. The main one being that the internal workings of the module are hidden from the rest of the application, thereby making maintenance easier and unwanted interactions less likely.

At work i am heavily using VB.NET with OOP. This is pretty good and, from my opinion, far away from what PB is even with modules. When you wrap your code in modules, PB should hide private stuff in the code completion window, which does not work in the beta yet. Also refactoring is an important feature when working with classes or modules. At the moment this is not available, too. And a 2-pass-compiler should be implemented to avoid silly declaration of code which has been already written elsewhere. If some people dont like that, maybe because of compilation time increase, they should be able to turn back to 1-pass in the compiler options dialog.

But i like the easyness of PB! No hidden or cryptic sources like in .Net (e.g. from the form designer). I am using an underscore as first character for private stuff like in Python code. Each procedure name of a module use it's own prefix, e. g. i wrote a HTML-parser and each procedure, structure, variable or constant starts with "Html". This works pretty good with current PB code completion, althought you can access the private code if you want but you know you shouldn't do that.

[luis]

At work i am heavily using VB.NET with OOP. This is pretty good and, from my opinion, far away from what PB is even with modules.

Yep, but OOP and modules are two different things... and we will never have OOP in PB according to Fred, so better get accustomed to it.

When you wrap your code in modules, PB should hide private stuff in the code completion window, which does not work in the beta yet.

Fred said this will be addressed, maybe not exactly what you are saying (would be nice) but at least limiting autocompletion to the specified module prefix (don't show all the rest outside).
Don't know if for the final release though, I have some doubts -> http://www.purebasic.fr/english/viewtop ... 71#p415671

And a 2-pass-compiler should be implemented to avoid silly declaration of code which has been already written elsewhere.

It seem it will not happen. Read from here on -> http://www.purebasic.fr/english/viewtop ... 01#p417001

[uwekel]

Thank you luis for your explanation and links. Indeed code completion is very important for me as well. I would have changed to Python language if code completion would be a bit better there. But it isn't in PB is good. No language is perfect, so we have to take this one with the least of your worries