Modules, conditional compilation, external constants

[luis]

I give up on trying to keep this thread on topic.

And a module is based on the concept of interface, the declaremodule section is the interface.
http://en.wikipedia.org/wiki/Modular_programming

[skywalk]

Sorry luis if you misinterpret the relevance of my suggestion. I can repost elsewhere if you like?
My intent is to minimize the amount of typing required to implement modules and make them more attractive.
I am not arguing the concept, only that the Declare section could be ascertained from within the Module block via Public prefixes.

[BorisTheOld]

.....only that the Declare section could be ascertained from within the Module block via Public prefixes.

A two pass compiler is needed to do that.

[skywalk]

I asked Fred that very question and he said no

[BorisTheOld]

I asked Fred that very question and he said no

I'm surprised.

If a 2 pass compiler isn't needed to implement a "public" attribute, then why is all that other "declare" stuff needed for forward referencing? Not just for modules, but for all PB code.

This is just a rhetorical question, because I don't plan to use the Module feature -- it's far too messy.

I find PB's OOP support much more to my liking.

[skywalk]

This is just a rhetorical question, because I don't plan to use the Module feature -- it's far too messy.

Exactly!
I applaud the introduction of Modules but I believe it could be more seamless.

I will continue in another post, because this is getting away from luis' question.

[luis]

@skywalk

Thanks. But you are welcome to stay here if you like, it' clear my question is not "felt", or even more probable there is not a really pretty solution to it using modules, fred posted here a couple of times already and if he wanted/were able to give a suggestion (or even a "yep, there is no other way") he would have already done it.
It's ok. I lost a lot of time on it without finding something comparable to cleanness of the original implementation, and what I came up it's not of my liking. Maybe I just looked at it for too long and I'm missing something. Hence the question.
But in the end modules as they are clearly are not for me and I will wait for a possible evolution.

About your request, here is my opinion: as I said the interface is part of the module concept. It's somewhat similar to prototype or declares, and it's useful when your code must interface with the module, so you just need to have the interface "handy" and you can write your code without even seeing the module implementation. The module can be 10000 lines, the interface maybe 50. If one module need to connect to another, again including the interface give to the former all the info it needs to use the latter. Moreover the compiler has a lot less work to do since it doesn't need to "build" the interface from the scope qualifiers buried in the code. And if in a remote future PB would ever permit to generate binary code for the modules (unlikely) again the interface would be absolutely necessary.

See ya

[helpy]

Currently works as follow:

the user of my lib knows he can customize some of it using specific constants, I set those consts to defaults values when they are not defined.

So if the user does nothing, the lib is compiled in its default configuration.

You can do this with Modules ...

library.pb:

Code: Select all

CompilerIf Defined( modLibrary_UserCompileOptions, #PB_Module ) = #False
	DeclareModule modLibrary_UserCompileOptions
	EndDeclareModule
CompilerEndIf

DeclareModule modLibrary_CompileOptions
	UseModule modLibrary_UserCompileOptions	
	
	CompilerIf Defined( LibDebug, #PB_Constant ) = #True
		#modLibDebug = #LibDebug
	CompilerElse
		#modLibDebug = #False
	CompilerEndIf
	
	CompilerIf Defined( LibOpt01, #PB_Constant ) = #True
		#modLibOpt01 = #LibOpt01
	CompilerElse
		#modLibOpt01 = #True
	CompilerEndIf
	
	CompilerIf Defined( LibOpt02, #PB_Constant ) = #True
		#modLibOpt02 = #LibOpt02
	CompilerElse
		#modLibOpt02 = #True
	CompilerEndIf
	
	CompilerIf Defined( LibOpt03, #PB_Constant ) = #True
		#modLibOpt03 = #LibOpt03
	CompilerElse
		#modLibOpt03 = #False
	CompilerEndIf
	
EndDeclareModule



DeclareModule modLibrary
	; Declaration of modLibrary
	Declare Init()
EndDeclareModule

Module modLibrary
	UseModule modLibrary_CompileOptions
	
	Procedure Init()
		CompilerIf #modLibDebug
			Debug "LibDebug = #True"
		CompilerElse
			Debug "LibDebug = #False"
		CompilerEndIf
		
		CompilerIf #modLibOpt01
			Debug "LibOpt01 = #True"
		CompilerElse
			Debug "LibOpt01 = #False"
		CompilerEndIf
		
		CompilerIf #modLibOpt02
			Debug "LibOpt02 = #True"
		CompilerElse
			Debug "LibOpt02 = #False"
		CompilerEndIf
		
		CompilerIf #modLibOpt03
			Debug "LibOpt03 = #True"
		CompilerElse
			Debug "LibOpt03 = #False"
		CompilerEndIf
	EndProcedure
EndModule

user.pb:

Code: Select all

DeclareModule modLibrary_UserCompileOptions
	#LibDebug = #True
	#LibOpt01 = #False
EndDeclareModule

modLibrary::Init()

It also works, if modLibrary_UserCompileOptions is not definied.

cu,
guido

[Josh]

But if the constants are passed as arguments to the compiler ...

Try with commandline:

Code: Select all

pbcompiler.exe test.pb /DEBUGGER /CONSTANT COMPILE_VARIANT_A=1

Are the constants set in commandline the same can be set in compiler options? IMHO, this one should be always callable too.

[luis]

@helpy

Guido, thank you very much.

As you see I did actually proposed the same thing as a possible solution

1) Having "Defined" supporting testing for modules I could test if the module lib_consts is defined and if it's not I could define it with the default constants. But this is not available for now.

But it wasn't available (or I didn't see it, I'm not really sure) when I wrote that. Has been added to beta 5.

This is acceptable, and solve one of my problems with modules.

Thanks again for the help

[helpy]

Maybe there should be something like CompilerConstants, which can be used globally with compiler directives:

Code: Select all

CompilerConstants
    #LibDebug = ...
    #ConstX = ...
EndCompilerConstants