Code: Select all
global.l someVariable
DeclareModule test
Declare.i MyFunc()
DeclareExternal.s AnExternalFunc()
ExternalVariable.l someVariable
EndDeclareModule
Code: Select all
global.l someVariable
DeclareModule test
Declare.i MyFunc()
DeclareExternal.s AnExternalFunc()
ExternalVariable.l someVariable
EndDeclareModule
If you have a dependency to some main scope or to some other module, it's a dependency either way. DeclareExternal is not a bad idea. IMO better would be a syntax to access the main scope (for all non-module symbols) and a PB:: scope for non-module PB-interal only. I think feature request in that direction exist.mk-soft wrote:This would create dependencies to the main program.
as already stated, it creates a dependency either way.mk-soft wrote:I think this would not correspond to the philosophy for modules.
This would create dependencies to the main program.
My thoughts exactly.#NULL wrote:IMO better would be a syntax to access the main scope (for all non-module symbols) and a PB:: scope for non-module PB-interal only. I think feature request in that direction exist.
I agree and I believe this magic aura around the concept of independence of modules is just an illusion.#NULL wrote: If you have a dependency to some main scope or to some other module, it's a dependency either way
Having the "::" to access the global scope does not mean you have to use it every time you write a module, it just means you don't have to make your life miserable writing long winded ugly code or using workarounds when the necessity arise. It's always better to have a choice.The idea of the module as a black box, unless we are talking about trivial examples, it's a myth which cannot be attained.
Even using the officially supported common module mechanism the importing module would obviously depend on the common one.
The importing module must also know the name of the common module it wants to import, whilst by using "::" (the global scope resolution which we don't have) it doesn't need to know anything, it can just assume what it needs it's there in the global scope like any other PB command and use it by prepending a "::" to the symbol name.
Even when you use some OS APIs in your module you depend on them and if the OS version change or an API is not present anymore your module is broken because an external dependency is missing.
So instead of trying to enforce some philosophical and unreal view I would prefer to have something flexible to use in real life and to be able to choose what's best on a case by case basis.
Well, it might depend on your definition of "trivial".The idea of the module as a black box, unless we are talking about trivial examples, it's a myth which cannot be attained.
Even when you use some OS APIs in your module you depend on them and if the OS version change or an API is not present anymore your module is broken because an external dependency is missing.
As you probably know, I would like to have the same module improvements as you. However, modules as they are currently provided by PureBasic, are already of great practical use. I don't want to miss them anymore. Your repeated general "module bashing" is not helpful.So instead of trying to enforce some philosophical and unreal view I would prefer to have something flexible to use in real life and to be able to choose what's best on a case by case basis.