1. Phix: How to Globalize(?) a Namespace Identifier

I have a file that includes a file with namespace IDs. Is there a way to work it?

-- helpers.e 
include manager.e as mgr 
-- primary_app.exw 
include helpers.e 
mgr:initiate() 

I tried using public and global, but I couldn't get them to work.

Is it possible?! Yes, I have to maintain this modularity. smile

new topic     » topic index » view message » categorize

2. Re: Phix: How to Globalize(?) a Namespace Identifier

No.

The idea that someone/anyone would want to use mgr: in primary_app.exw without declaring mgr totally complexes me, and always has. When I see mgr: and the source file does not tell me where I should look, well that's just plain rude.

The use of "namespace helpers" in helpers.e so you do not have to say "as helpers" on the include likewise befuddles me and has only been added rather reluctantly, and probably has "bugs", one of which will almost certainly bite you if you try to do the first of what I am about to suggest.

Either:

include helpers.e as helpers 
include helpers.e as mgr 

or

include helpers.e as helpers 
include manager.e as mgr 

or

helpers:initiate()   -- [1] 

or

initiate_mgr()  -- [2] 

There are no doubt plenty of other ways, such as using routine_ids.

[1]: Uses the include-tree to resolve, assumes that helpers.e does not also contain/include skivvies:initiate()
[2]: I always have and always will maintain that is the best solution. As a bonus a simple search gets exactly what I want, rather than a list of two dozen or more to pick from.

PS: The whole point of namespaces is to resolve clashing globals. If you allow namespaces to be global then by rights you would also have to invent an entirely new mechanism to resolve clashing global namespaces.
Suppose John ships his helpful utilities library with util:init().
And then Jim also ships a library with util:init().
With "include as" being the place where util is defined, the solution for using both is trivial.
With "namespace util" in both you would require a sub-include mechanism to avoid the conflict, but it is doable.
With "global namespace util" you would have no option but to modify their sources every time they issued a new version.

new topic     » goto parent     » topic index » view message » categorize

3. Re: Phix: How to Globalize(?) a Namespace Identifier

Here are the discussions on the rapdieuphoria-develop mailing list from 2008 regarding how they arrived at the current functionality in Euphoria.

(I find it amusing that this topic is being discussed on the same days of the year as it was back then.)

-Greg

new topic     » goto parent     » topic index » view message » categorize

4. Re: Phix: How to Globalize(?) a Namespace Identifier

petelomax said...

The idea that someone/anyone would want to use mgr: in primary_app.exw without declaring mgr totally complexes me, and always has. When I see mgr: and the source file does not tell me where I should look, well that's just plain rude.

That's a good point, and I was probably going overboard on my attempt to make more modular my code scaffold.

In my primary app, I was including this helper app which included other modules that my primary app would need. These other modules are all namespaced with "as ..."

I'll probably just move those includes back into the primary source. It just means that I cannot use an include file that includes other modules.

If I do this:

-- mods.e 
public include helper.e as help 

then the "help" namespace should propagate to any parent source... no?

include mods.e 
help:package() 

or (?)

public include mods.e 
help:package() 
new topic     » goto parent     » topic index » view message » categorize

5. Re: Phix: How to Globalize(?) a Namespace Identifier

euphoric said...

If I do this:

-- mods.e 
public include helper.e as help 

then the "help" namespace should propagate to any parent source... no?

include mods.e 
help:package() 

No. You are still trying to use/thinking of namespaces as global. It works the other way round, you can use help: to refer to sub-includes of helper.e (but only in mods.e, where help: is defined), or if you include mods.e as mods then mods:package() is fine even though package() is actually in the helper.e sub-include of mods.e.

Phix makes no distinction whatsoever between "include" and "public include", it quietly ignores the "public" (only) for compatibility with Euphoria.

Should you want to bore yourself to tears, and/or burn out a few grey cells, at the start of psym.e you can find a quite detailed essay on Phix include handling.

new topic     » goto parent     » topic index » view message » categorize

6. Re: Phix: How to Globalize(?) a Namespace Identifier

ghaberek said...

Here are the discussions on the rapdieuphoria-develop mailing list from 2008 regarding how they arrived at the current functionality in Euphoria.

(I find it amusing that this topic is being discussed on the same days of the year as it was back then.)

-Greg

Hah! I particularly enjoyed my own conspicuous absence from all that particularly vacuous nonsense! smile

I have always been in the ftp_open() is better than ftp:open() camp, and recall 3 or 4 years ago being slightly apprehensive over banning builtin overrides in Phix, but in all the time since, doing so has not bitten me back even once.

new topic     » goto parent     » topic index » view message » categorize

7. Re: Phix: How to Globalize(?) a Namespace Identifier

I have just tried it on 4..1, and namespaces are also local only in Open Euphoria.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu