OpenEuphoria

RE: [RC] Lucius tries to use namespace

• Posted by kbochert at copper.net Jun 25, 2003
• 406 views

On 25 Jun 2003 at 13:36, Matt Lewis wrote:

> 
> 
> > From: Al Getz [mailto:Xaxo at aol.com]
> > > irvm at ellijay.com wrote:
> 
> <snip>
> 
> > > To write a program using GTK, I have a choice:
> > > 
> > > Option 1:
> > > I can specifically 'include ... as ..." each individual GTK 
> > > control from its own Eu include file. That makes 124 lines
> > > of "include ... as"
> 
> <snip>
> 
> > > Option 2:
> > > I could write a wrapper for all these includes, and just 
> > > put a single line: 
> > > "include wrapper"
> 
> <snip>
> 
> > > But what happens when I try to access these functions from my main 
> > > program (the one which just 'include(s) wrapper') ?
> > > I get an error message telling me that:
> 
> <snip>
> 
> > > So I'll just qualify the function, right? 
> > > entry:set_text("Hello World")
> > > 
> > > Wrong again!
> > > entry has not been declared.
> 
> <snip>
> 
> > > Q: If Eu can pass on the names of included files, as 
> > > well as the names of all the globals in those files, why 
> > > can't it also pass on the namespace qualifiers given to
> > > those files?
> 
> > I didnt have that much of a problem when i wrote the WinClass 
> > Library, which depends highly on the use of namespaces for
> > naming its classes.
> 
> I think you missed Irv's point.  The current namespacing issue helps us as
> long as we're only concerned about include files one level down, but as has
> been discussed recently, leaves a lot to be desired when there are more
> levels than that (and there always are!).  In your example, in every file in
> which you wanted to use 'SLE:' or 'MLE:' you'd have to write 'include ... as
> SLE'.  And do that for *every* class for *every* file.  What would make
> sense to me would simply be the ability to access namespaces from within
> namespaces:
> 
> --file1
> global atom x
> 
> --file2
> global atom x
> 
> --file3
> include file1 as f1
> include file2 as f2
> 
> --file4
> include file3 as f3
> 
> f3:f1:x=1
> f3:f2:x=2
> 
> I think that this should solve most of the problems that have been discussed
> here regarding namespacing problems and libraries (assuming that we all
> start using namespaces for all global accesses).  I think it should be
> fairly easy for Rob to implement within Euphoria--just expand the scope
> checking algorithm to allow chained namespaces (if I get any spare time,
> I'll see if I can do this in the Eu source myself--or maybe Karl could try
> it? :).

I'm not sure I like the idea of nested namespaces.
You got me thinking (again!) of how I want Bach to handle the
issue.
Unfortunately, my proposed solution is not a simple  change to
the current mechanism. The problems that namespaces try to
solve are many -- no one solution that I can imagine can solve, or
even ease, them all.
My proposal would include:
1) as        -- just like now.
2) import  -- to restrict the visibility of globals.
3) rename -- to handle occaisional clashes.
4) redefine -- to extend existing features.
5) shadowing selectable 'with shadow or 'shadow include foo.e'
6) features included without 'as' are in a namespace named like the file
    as well as the global namespace.

To my mind, any less comprehensive approach can do more harm
than good.
Of course it is not clear that the above solution is comprehensive
enough, or even workable.
If there are questions I will publish more details on the OpenEu
forum -- this has not a prayer of getting into Eu.