Declare External Variables &procedures for use w/in a module

[jassing]

Would be nice to have a way to declare a procedure as 'external' to the module; something like:

Code: Select all

global.l someVariable
DeclareModule test
  Declare.i MyFunc()
  DeclareExternal.s AnExternalFunc()
  ExternalVariable.l someVariable
EndDeclareModule

[mk-soft]

I think this would not correspond to the philosophy for modules.
This would create dependencies to the main program.

In my opinion it is better in this case to work with common modules.

So from my side a
-1

[#NULL]

This would create dependencies to the main program.

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.
Protecting the main scope from module symbols is a good idea. But completely protecting a module from any other non-module code (not even as optional explicit access) takes it away with the other hand.

[jassing]

I think this would not correspond to the philosophy for modules.
This would create dependencies to the main program.

as already stated, it creates a dependency either way.
And since it's explicitly declared, it wouldn't impact the philosophy for modules by default, but rather enhance the concept of it.
I respect your opinion, but it shouldn't discount others.

[Little John]

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.

My thoughts exactly.
See also viewtopic.php?p=529066#p529066

[luis]

If you have a dependency to some main scope or to some other module, it's a dependency either way

I agree and I believe this magic aura around the concept of independence of modules is just an illusion.

I loosely quote myself:

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.

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.

[skywalk]

I was eager for the module namespace but its implementation is not file based.
It places extra syntax burdens on the coder(many declares) that should/could have been automated by the compiler.
But, maybe not entirely if single pass?
For now, I use my own xxx_MyFunction(), yyy_MyFunction() namespaces and never have a problem.
Globals are always available and without "::" everywhere in my code.
And I never remember pointer, addressof, and prototype rules with "::"?
::*MyFunction() or *::MyFunction(), etc.

[Little John]

Luis, you are exaggerating a bit.

The idea of the module as a black box, unless we are talking about trivial examples, it's a myth which cannot be attained.

Well, it might depend on your definition of "trivial".
Personally, I do not consider e.g. this module viewtopic.php?f=12&t=45787
or this one viewtopic.php?p=524997#p524997 trivial.
In the meantime, many people have provided modules here that demonstrate how useful modules can be.

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.

And when the power supply of your computer is broken, you also can't use your modules anymore ... Of course nothing in the world is completely independent from everything else -- and nobody said that.

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.

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.