1. RE: [RC] Lucius tries to use namespace
irvm at ellijay.com wrote:
>
>
> Lucius, in all his subtlety, is just saying what anyone who has taken a
> close look at 'namespaces' must be thinking.
>
> I had hoped that Rob would come up with a brilliant, (and perhaps
> uexpected)
> solution to the namespace problem. He sometimes does that sort of thing.
> What we got instead was more like a band-aid for a broken leg -
> while it might be needed, it's also completely inadequate.
>
> The problem is not, however, as Lucius stated: that you must prefix each
>
> namespaced variable/function. That is a minor annoyance, and would have
> been even less of a problem if Rob had listened to the numerous
> suggestions
> that he implement something along the lines of Pascal's 'with .... do'
> statement.
>
> The real problem is that namespacing is braindead.
>
> Let's look at a real-life example:
> In GTK, there are many controls which have similarly but logically named
>
> functions, for example: get_text(). Some of these functions take
> different
> parameters than others.
>
> 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" at the
> top of each program for any program which uses more than a few
> controls. Get real - this entre post is only about 100 lines long.
> Do you really want that much prelude to each of your programs?
>
> Option 2:
> I could write a wrapper for all these includes, and just put a single
> line:
> "include wrapper"
> at the top of each new program. A much better solution, right?
>
> Wrong. **
> While in the wrapper, each include has its own identity
> (the name I chose when "including .. as"). For example:
> include entry.e as entry
> include textbox.e as textbox
>
> This eliminates name collisions inside the wrapper, because I can
> refer to "entry:set_text()" or "textbox:set_text()".
>
> 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:
> A namespace qualifier is needed to resolve set_text.
> set_text is defined as a global symbol in:
> entry.e
> textbox.e
> textedit.e
> label.e
> button.e ....etc
>
> So Euphoria knows there are several versions of "set_text()" out there,
> and even which files they are found in, even though I did not
> specifically
> "include" ANY of those files in my main program. Cool.
>
> So I'll just qualify the function, right?
> entry:set_text("Hello World")
>
> Wrong again!
> entry has not been declared.
>
> How does Eu know where all these "set_text()" functions are located?
> It got that info from the "wrapper", where they _were_ included,
> obviously.
>
> ---------------
> 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?
>
> Ans: Braindead.
> ---------------
>
> OK, Rob will say namespacing wasn't designed for that purpose, but
> only to make it easier to include libraries written by other people.
> Perhaps he will explain how using a library from someone else
> differs from using the identical library written by oneself.
>
> ** note: I managed to work around that problem, but the solution sure
> didn't involve using namespaces. It would have been *much* simpler if
> proper namespacing had been implemented.
>
> Irv
>
>
<snip>
Hello again Irv,
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.
SetText() is an interesting example too, because there are lots
of those functions, in most of the classes.
To set the text for a single line edit control, you would type
SLEdit:SetText(ID,"Text 1")
but for a multiline edit control you would type
MLEdit:SetText(ID,"Text 2")
but these could be shortened to
SLE:SetText(ID,"Text 1")
and
MLE:SetText(ID,"Text 2")
if you use the shorter namespace names.
So you see it does in fact work out well.
If it didnt, i could have never have done it this way.
The only time a problem comes up is when you try to
include a library that incorporates other namespace
usage conventions.
The best conventions would probably be:
[1]
any file that comes with Euphoria never gets a namespace
(get.e, file.e, etc.)
any file you write yourself always gets a namespace
(DoThis.ew, DoThat.ew, etc)
This works out pretty well, except it's also nice to
include the Windows constants without a namespace also,
and a very few number of atoms that need to be global
to the whole program (such as the 'this' pointer).
--these two dont get namespace names:
include WConst.ew
include WM_Const.ew
Now a constant like
WS_OVERLAPPEDWINDOW
doesnt have to be prefixed.
Part of the reason i wrote that library is to get a feel for
what namespaces are all about and how they can be used.
I agree that there could be improvements, but it does
work right now to some degree.
Take care for now,
Al
2. RE: [RC] Lucius tries to use namespace
> 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? :). Of course, this amounts to lots of namespace typing, which seems to
beg for Irv's request of block namespace use, though this would probably get
a lot more involved on the implementation side.
Matt Lewis
3. RE: [RC] Lucius tries to use namespace
- Posted by kbochert at copper.net
Jun 25, 2003
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.
4. RE: [RC] Lucius tries to use namespace
Matt Lewis wrote:
>
> 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...
>
> Matt Lewis
>
I see what you mean. You're looking to inherit namespaces
from other includes. This sounds pretty good. Im not sure
if i want to make my libs users have to type more then one
namespace prefix, but if the include could inherit the prefixes
verbatim that might also take care of that too...
inherit LargeLib.ew
xx:GetStuff() -- xx was a namespace prefix in LargeLib.ew
--LargeLib.ew:
--------------------------------------------------------------
include GetThings.ew as xx --has the GetStuff() function.
include GetOtherThings.ew as xy
--------------------------------------------------------------
I guess this would take some thought, and there would have to
be a way to eliminate some namespaces too, or override them.
For now, each namespace has to be typed in each file that
you intend to use the class in:
include SLEdit.ew as SLE
has to appear in each file it's true, but that isnt very hard
because once you type in your first list of most of the classes,
you copy/paste the list into the new file. You then delete
what you dont want to use in that file.
If you look at any kind of includes in Euphoria you'll find that the
includes couldnt dig down into subdirectories either 
which also bugged me a little. Perhaps we need to be able to
include a whole directory too...
include "c:\Euphoria\MyIncludes\"
or a file that was included will look into it's current directories
for files too...
include c:\Euphoria\Include\MyLib\Lib1.ew
where Lib1.ew has includes also residing in the MyLib directory.
Generally speaking, the namespace feature makes the language
a little more complex, and so there are certainly going to be
people who dont like using it, at least until they decide to
learn the best way to deal with it. On the plus side, complexity
usually leads to increased functionality, and i believe that the
namespace feature in Euphoria has increased it's basic functionality
by 1000 percent, even the way it stands now. This means that
if those same people decide to learn to use the namespace feature
to at least some degree they will find the language can work
better for them in the long run.
I hope to write more on this soon too...
Take care for now,
Al
5. RE: [RC] Lucius tries to use namespace
Al Getz wrote:
> I see what you mean. You're looking to inherit namespaces
> from other includes. This sounds pretty good. Im not sure
> if i want to make my libs users have to type more then one
> namespace prefix, but if the include could inherit the prefixes
> verbatim that might also take care of that too...
Well, they wouldn't *have* to do that. They could always go ahead and
re-include the files with their own namespace qualifiers if needed, but
it would certainly be a huge convenience, because you could take Irv's
idea of a wrapper that includes the files into namespaces, and not have
to retype, etc. Plus, the namespacing would likely be more consistent
from app to app.
-- gtk_wrapper.e
include button.e as button
include textbox.e as text
-- ...etc
--my_app.exu
include gtk_wrapper.e as gtk
gtk:button:create()
gtk:text:set_text( "Hello World" )
Matt Lewis
