1. RE: [RC] Lucius tries to use namespace
- Posted by Al Getz <Xaxo at aol.com> Jun 25, 2003
- 435 views
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
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Jun 25, 2003
- 400 views
> 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
- 407 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.
4. RE: [RC] Lucius tries to use namespace
- Posted by Al Getz <Xaxo at aol.com> Jun 26, 2003
- 434 views
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
- Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Jun 26, 2003
- 437 views
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