1. A Problem with v2.4 (for Rob)
- Posted by Al Getz <Xaxo at aol.com> May 14, 2003
- 443 views
Hello again Rob, While working with v2.4 i came upon a problem that has quite profound consequences. The problem centers around the new implementation of 'include as'. --in file SomeoneElsesExistingFuncs.ew-------- procedure DoSomething() ?{1} end procedure -- and 100 other procedures already named. ---------------------------------------------- --in file MyNewFuncs.ew----------------------- procedure DoSomething() ?{2} end procedure -- and 99 other procedures, a lot with the same -- names as in SomeoneElsesExistingFuncs.ew ---------------------------------------------- -- MyNewFuncs.ew DoSomething() does something slightly different -- then that which is in SomeoneElsesExistingFuncs.ew -- all the following in file Test.exw ... include SomeoneElsesExistingFuncs.ew include MyNewFuncs.ew as MF -------Someone elses existing .exw code section--------- DoSomething() -- and call 100 other functions already named in -- SomeoneElsesExistingFuncs.ew --------------------------------------------------- -------My new code section (also in Text.exw)--------- MF:DoSomething() --<----flags a name qualifier required error. -- and call 99 other functions already named in -- both MyNewFuncs.ew ------------------------------------------------------- The interpreter flags a name qualifier required error because it doesnt see that "MF:DoSomething()" is different then simply "DoSomething()". This is exactly the same as Euphoria 2.2. This reduces the value of 'include as' in programming technique. You should be able to block completely the new code so as to provide perfect encapsulation without having to change var names. This means that either one of two things has to happen: 1. rename all the procedures in SomeoneElsesExistingFuncs.ew 2. rename all the procedures in MyNewFuncs.ew Isnt this exactly the same as it was before v2.3 i think? If someone wants to include a file both without a name qualifier and with a name qualifier all they have to do is use the following code: include TheirFile.ew as TF include TheirFile.ew and that would acheive the same thing that exists now. This means if the interpreter is changed to stop recognition of globals in files that are exclusively included with 'include as' then this default action can be turned on or off by either using one line of code or two (as above). This really has a big effect on what you can and cant write when it might be used with other peoples include files. Once this works it's going to be very useful. The impact on the code that can be allowed will be incredible. Take care for now, Al
2. Re: A Problem with v2.4 (for Rob)
- Posted by Derek Parnell <ddparnell at bigpond.com> May 14, 2003
- 427 views
On Wed, 14 May 2003 02:37:25 +0000, Al Getz <Xaxo at aol.com> wrote: > > Hello again Rob, > > While working with v2.4 i came upon a problem that has > quite profound consequences. The problem centers around > the new implementation of 'include as'. > > > --in file SomeoneElsesExistingFuncs.ew-------- > procedure DoSomething() > ?{1} > end procedure > -- and 100 other procedures already named. > ---------------------------------------------- > > --in file MyNewFuncs.ew----------------------- > procedure DoSomething() > ?{2} > end procedure > -- and 99 other procedures, a lot with the same > -- names as in SomeoneElsesExistingFuncs.ew > > ---------------------------------------------- > > -- MyNewFuncs.ew DoSomething() does something slightly different > -- then that which is in SomeoneElsesExistingFuncs.ew > > > -- all the following in file Test.exw ... > > include SomeoneElsesExistingFuncs.ew > include MyNewFuncs.ew as MF > > > -------Someone elses existing .exw code section--------- > DoSomething() > -- and call 100 other functions already named in > -- SomeoneElsesExistingFuncs.ew > --------------------------------------------------- > > -------My new code section (also in Text.exw)--------- > MF:DoSomething() --<----flags a name qualifier required error. > -- and call 99 other functions already named in > -- both MyNewFuncs.ew > ------------------------------------------------------- > > The interpreter flags a name qualifier required error because > it doesnt see that "MF:DoSomething()" is different then simply > "DoSomething()". This is exactly the same as Euphoria 2.2. That is not quite what is happening. Euphoria sees "DoSomething()" so it looks for a local routine with this name. If it can't find one, it looks for a global routine with this name. In this case it finds two global routines with this name. Now, which one did you actually mean to use? How would Euphoria know? For example, if it assumes that because you didn't use the namespace qualifier that it should use the routine in a file that wasn't namespaced? Maybe, but that assumes you INTENDED to leave off the namespace qualifier. Rather than second guess you, Euphoria raises an error so that you can disambiguate the situation. > This reduces the value of 'include as' in programming technique. > You should be able to block completely the new code so as to > provide perfect encapsulation without having to change > var names. You can - and using the current Euphoria. > This means that either one of two things has to happen: > 1. rename all the procedures in SomeoneElsesExistingFuncs.ew > 2. rename all the procedures in MyNewFuncs.ew Ah hah! There is a third alternative. 3. Add a namespace qualifier on the "include SomeoneElsesExistingFuncs.ew" Exmaple: include SomeoneElsesExistingFuncs.ew SE include MyNewFuncs.ew as MF -------Someone elses existing .exw code section--------- -- Explicitly tell Eu that you want somebody else's routine. SE:DoSomething() -- and call 100 other functions already named in -- SomeoneElsesExistingFuncs.ew --------------------------------------------------- -------My new code section (also in Text.exw)--------- -- Explicitly tell Eu that you want your routine. MF:DoSomething() > Isnt this exactly the same as it was before v2.3 i think? > > If someone wants to include a file both without a name qualifier > and with a name qualifier all they have to do is use the following > code: > include TheirFile.ew as TF > include TheirFile.ew > > and that would acheive the same thing that exists now. Which is nothing. A file only gets included once - no matter how many times you refer to it. In fact... include TheirFile.ew as TF include TheirFile.ew as YG include TheirFile.ew as UH just creates namespace aliases for the same file. In other words ... TF:DoSomething() YG:DoSomething() UH:DoSomething() all refer to exactly the same routine. > This means if the interpreter is changed to stop recognition > of globals in files that are exclusively included > with 'include as' then this default action can be turned on > or off by either using one line of code or two (as above). I'm not sure what you are saying here. Are you saying ... All globals defined in a file that has been included with the "as" phrase must ONLY be referred to by using the namespace qualifier - and thus if a symbol is not namespace-qualified in your code, Euphoria must not look in files that were included with a namespace qualifier > This really has a big effect on what you can and cant write > when it might be used with other peoples include files. > > Once this works it's going to be very useful. The impact > on the code that can be allowed will be incredible. I agree that this would help your situation a lot. Maybe a warning might be useful in case the coder just forgot to qualify a reference or two. It would also potentially break existing code - but maybe not that much. -- cheers, Derek Parnell
3. Re: A Problem with v2.4 (for Rob)
- Posted by Juergen Luethje <j.lue at gmx.de> May 14, 2003
- 414 views
Hello Derek, you wrote: > On Wed, 14 May 2003 02:37:25 +0000, Al Getz <Xaxo at aol.com> wrote: > >> >> Hello again Rob, >> >> While working with v2.4 i came upon a problem that has >> quite profound consequences. The problem centers around >> the new implementation of 'include as'. >> >> >> --in file SomeoneElsesExistingFuncs.ew-------- >> procedure DoSomething() >> ?{1} >> end procedure >> -- and 100 other procedures already named. >> ---------------------------------------------- >> >> --in file MyNewFuncs.ew----------------------- >> procedure DoSomething() >> ?{2} >> end procedure >> -- and 99 other procedures, a lot with the same >> -- names as in SomeoneElsesExistingFuncs.ew >> >> ---------------------------------------------- >> >> -- MyNewFuncs.ew DoSomething() does something slightly different >> -- then that which is in SomeoneElsesExistingFuncs.ew >> >> >> -- all the following in file Test.exw ... >> >> include SomeoneElsesExistingFuncs.ew >> include MyNewFuncs.ew as MF >> >> >> -------Someone elses existing .exw code section--------- >> DoSomething() >> -- and call 100 other functions already named in >> -- SomeoneElsesExistingFuncs.ew >> --------------------------------------------------- >> >> -------My new code section (also in Text.exw)--------- >> MF:DoSomething() --<----flags a name qualifier required error. >> -- and call 99 other functions already named in >> -- both MyNewFuncs.ew >> ------------------------------------------------------- >> >> The interpreter flags a name qualifier required error because >> it doesnt see that "MF:DoSomething()" is different then simply >> "DoSomething()". This is exactly the same as Euphoria 2.2. > > That is not quite what is happening. Euphoria sees "DoSomething()" so it > looks for a local routine with this name. If it can't find one, it looks > for a global routine with this name. In this case it finds two global > routines with this name. Maybe I'm wrong, but in my understanding the two global routines have *different* names: One name is 'DoSomething()', and the other name is 'MF:DoSomething()'. > Now, which one did you actually mean to use? How > would Euphoria know? For example, if it assumes that because you didn't use > the namespace qualifier that it should use the routine in a file that > wasn't namespaced? Yes. Isn't this situation similar to that one, when you start a program say 'myprog.exe' from the command line? If the program is in the current directory or in a directory on the PATH, and you want to run this one, you just have to type 'myprog.exe'. If you want to run another program with this name in another directory that is not on the PATH, you can do this by typing the full qualified name, e.g. 'C:\test\myprog.exe'. > Maybe, but that assumes you INTENDED to leave off the > namespace qualifier. Yes. > Rather than second guess you, Euphoria raises an error > so that you can disambiguate the situation. [big snip] > Maybe a warning might be > useful in case the coder just forgot to qualify a reference or two. It > would also potentially break existing code - but maybe not that much. Yes, IMHO a warning -- instead of an error -- would be the appropriate reaction here (if it doesn't break too much existing code). Best Regards, Juergen -- /"\ ASCII ribbon campain | |\ _,,,---,,_ \ / against HTML in | /,`.-'`' -. ;-;;,_ X e-mail and news, | |,4- ) )-,_..;\ ( `'-' / \ and unneeded MIME | '---''(_/--' `-'\_)
4. Re: A Problem with v2.4 (for Rob)
- Posted by Derek Parnell <ddparnell at bigpond.com> May 15, 2003
- 432 views
----- Original Message ----- From: "Juergen Luethje" <j.lue at gmx.de> To: "EUforum" <EUforum at topica.com> Subject: Re: A Problem with v2.4 (for Rob) > > Hello Derek, you wrote: [snip] > > > > That is not quite what is happening. Euphoria sees "DoSomething()" so it > > looks for a local routine with this name. If it can't find one, it looks > > for a global routine with this name. In this case it finds two global > > routines with this name. > > Maybe I'm wrong, but in my understanding the two global routines have > *different* names: One name is 'DoSomething()', and the other name is > 'MF:DoSomething()'. Well if that was the case then Euphoria would not complain about having to need a namespace to remove an ambiguous reference, because there would be no ambiguous reference if they had different names. > > Now, which one did you actually mean to use? How > > would Euphoria know? For example, if it assumes that because you didn't use > > the namespace qualifier that it should use the routine in a file that > > wasn't namespaced? > > Yes. Isn't this situation similar to that one, when you start a program > say 'myprog.exe' from the command line? If the program is in the current > directory or in a directory on the PATH, and you want to run this one, > you just have to type 'myprog.exe'. If you want to run another program > with this name in another directory that is not on the PATH, you can do > this by typing the full qualified name, e.g. 'C:\test\myprog.exe'. MS-DOS has built in rules about how to search for for program files. The most important, in this context, is that it STOPS searching when it finds one that matches the one you typed in. It does not find ALL possible matching files then tries to decide which to run. Euphoria does look for all matching ids. > > Maybe, but that assumes you INTENDED to leave off the > > namespace qualifier. > > Yes. But how would Eu know that. You could have just forgotten to put it on. ---------------- cheers, Derek Parnell
5. Re: A Problem with v2.4 (for Rob)
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> May 15, 2003
- 419 views
On Wed, 14 May 2003 02:37:25 +0000, Al Getz <Xaxo at aol.com> wrote: Al, the example you gave worked fine, flagging the line of code in your program which now needs a namespace qualifier. The following shows how to get this problem in a way that would force you to edit someone elses code: --Someone else's code: lib1.e is: include subs1.e d() subs1.e is: global procedure d() ?{1} end procedure --Another persons code: lib2.e is: include subs2.e d() subs2.e is: global procedure d() ?{2} end procedure --Your code can then have all the namespace qualifiers you can shake a --stick at, it will always bomb (even with your include twice idea): include lib1.e as x include lib2.e as y What I think is needed is that if you are "inside" an include as statement, then it should automatically select globals defined since that "as" directive over any defined beforehand. You would still have the task, when you have reams of existing, non-namespace qualified code, of a global edit (which really you must admit is not that difficult - I do it all the time. Maybe your editor is not up to scratch - Try Meditor Pete
6. Re: A Problem with v2.4 (for Rob)
- Posted by Juergen Luethje <j.lue at gmx.de> May 18, 2003
- 416 views
Hello Derek, you wrote: > From: "Juergen Luethje" <j.lue at gmx.de> >> Hello Derek, you wrote: > > [snip] > >>> >>> That is not quite what is happening. Euphoria sees "DoSomething()" so it >>> looks for a local routine with this name. If it can't find one, it looks >>> for a global routine with this name. In this case it finds two global >>> routines with this name. >> >> Maybe I'm wrong, but in my understanding the two global routines have >> *different* names: One name is 'DoSomething()', and the other name is >> 'MF:DoSomething()'. > > Well if that was the case then Euphoria would not complain about having to > need a namespace to remove an ambiguous reference, because there would be no > ambiguous reference if they had different names. I meant: From a logical point of view, I regard 'DoSomething()' and 'MF:DoSomething()' as two different names. I know, that Euphoria can't realize that at the moment, but I don't see any logical reason, why. >>> Now, which one did you actually mean to use? How >>> would Euphoria know? For example, if it assumes that because you didn't use >>> the namespace qualifier that it should use the routine in a file that >>> wasn't namespaced? >> >> Yes. Isn't this situation similar to that one, when you start a program >> say 'myprog.exe' from the command line? If the program is in the current >> directory or in a directory on the PATH, and you want to run this one, >> you just have to type 'myprog.exe'. If you want to run another program >> with this name in another directory that is not on the PATH, you can do >> this by typing the full qualified name, e.g. 'C:\test\myprog.exe'. > > MS-DOS has built in rules about how to search for for program files. The > most important, in this context, is that it STOPS searching when it finds > one that matches the one you typed in. It does not find ALL possible > matching files then tries to decide which to run. Euphoria does look for all > matching ids. Yes, of course. The idea only works, if there is not more that one of those "critical" include files without a namespace identifier. E.g. given 3 include files with identical code, using include file1.e include file2.e include file3.e as i3 cannot work. But using include file1.e include file2.e as i2 include file3.e as i3 should work, because any file has an unambiguous namespace. file1.e has the namespace "" which is not nothing. Eu IMHO should be able to handle that. >>> Maybe, but that assumes you INTENDED to leave off the >>> namespace qualifier. >> >> Yes. > > But how would Eu know that. You could have just forgotten to put it on. Eu can't know that, unless Rob gives us a "do what I mean, not what I say" (DWIM) interpreter. There are many other situations, were Eu must rely on the assumption, that what I wrote, was what I intended to write. In contrast to Eu, I know what I want, and at the moment, Eu forces me *unnecessarily* to write things, that I don't want. Al already wrote in more detail about that in the meantime. Best regards, Juergen -- /"\ ASCII ribbon campain | |\ _,,,---,,_ \ / against HTML in | /,`.-'`' -. ;-;;,_ X e-mail and news, | |,4- ) )-,_..;\ ( `'-' / \ and unneeded MIME | '---''(_/--' `-'\_)
7. Re: A Problem with v2.4 (for Rob)
- Posted by jbrown1050 at hotpop.com May 18, 2003
- 431 views
In my namespace parser, when looking for "DoSomething", it would first look at the local routines, then the global ones. If still no match, then it would look at the namespaces, one-by-one, (in the order they were created) until it found a match. If no match was found then it raised an error. Note that my parser didn't raise an error if there were _2_ DoSomeThing's, since it stopped after it had found _1_. That is arguably a flaw, but perhaps not. (I'm hinting at how the RDS version of namespaces could be improved, btw, not at getting more people to use my namespace parser, in case you didn't get that ... my parser was designed for Eu 2.2, pre-namespaces.) jbrown On Sun, May 18, 2003 at 06:57:52PM +0200, Juergen Luethje wrote: > > Hello Derek, you wrote: > > > From: "Juergen Luethje" <j.lue at gmx.de> > >> Hello Derek, you wrote: > > > > [snip] > > > >>> > >>> That is not quite what is happening. Euphoria sees "DoSomething()" so it > >>> looks for a local routine with this name. If it can't find one, it looks > >>> for a global routine with this name. In this case it finds two global > >>> routines with this name. > >> > >> Maybe I'm wrong, but in my understanding the two global routines have > >> *different* names: One name is 'DoSomething()', and the other name is > >> 'MF:DoSomething()'. > > > > Well if that was the case then Euphoria would not complain about having to > > need a namespace to remove an ambiguous reference, because there would be no > > ambiguous reference if they had different names. > > I meant: From a logical point of view, I regard 'DoSomething()' and > 'MF:DoSomething()' as two different names. I know, that Euphoria can't > realize that at the moment, but I don't see any logical reason, why. > > >>> Now, which one did you actually mean to use? How > >>> would Euphoria know? For example, if it assumes that because you didn't > >>> use > >>> the namespace qualifier that it should use the routine in a file that > >>> wasn't namespaced? > >> > >> Yes. Isn't this situation similar to that one, when you start a program > >> say 'myprog.exe' from the command line? If the program is in the current > >> directory or in a directory on the PATH, and you want to run this one, > >> you just have to type 'myprog.exe'. If you want to run another program > >> with this name in another directory that is not on the PATH, you can do > >> this by typing the full qualified name, e.g. 'C:\test\myprog.exe'. > > > > MS-DOS has built in rules about how to search for for program files. The > > most important, in this context, is that it STOPS searching when it finds > > one that matches the one you typed in. It does not find ALL possible > > matching files then tries to decide which to run. Euphoria does look for all > > matching ids. > > Yes, of course. The idea only works, if there is not more that one of > those "critical" include files without a namespace identifier. > E.g. given 3 include files with identical code, using > include file1.e > include file2.e > include file3.e as i3 > > cannot work. > But using > include file1.e > include file2.e as i2 > include file3.e as i3 > > should work, because any file has an unambiguous namespace. file1.e has > the namespace "" which is not nothing. Eu IMHO should be able to handle > that. > > >>> Maybe, but that assumes you INTENDED to leave off the > >>> namespace qualifier. > >> > >> Yes. > > > > But how would Eu know that. You could have just forgotten to put it on. > > Eu can't know that, unless Rob gives us a "do what I mean, not what I > say" (DWIM) interpreter. > There are many other situations, were Eu must rely on the assumption, > that what I wrote, was what I intended to write. > In contrast to Eu, I know what I want, and at the moment, Eu forces me > *unnecessarily* to write things, that I don't want. > Al already wrote in more detail about that in the meantime. > > Best regards, > Juergen > > -- > /"\ ASCII ribbon campain | |\ _,,,---,,_ > \ / against HTML in | /,`.-'`' -. ;-;;,_ > X e-mail and news, | |,4- ) )-,_..;\ ( `'-' > / \ and unneeded MIME | '---''(_/--' `-'\_) > > > > TOPICA - Start your own email discussion group. FREE! > -- /"\ ASCII ribbon | http://www.geocities.com/jbrown1050/ \ / campain against | Linux User:190064 X HTML in e-mail and | Linux Machine:84163 /*\ news, and unneeded MIME |
8. Re: A Problem with v2.4 (for Rob)
- Posted by Derek Parnell <ddparnell at bigpond.com> May 19, 2003
- 413 views
On Sun, 18 May 2003 22:58:07 +0000, Al Getz <Xaxo at aol.com> wrote: > > > Juergen Luethje wrote: >> Eu can't know that, unless Rob gives us a "do what I mean, not what I >> say" (DWIM) interpreter. >> There are many other situations, were Eu must rely on the assumption, >> that what I wrote, was what I intended to write. > > Again, i cant agree more, and you pretty much summed it up > > > if i type > > atom x > x=1 > > i dont get an error saying > > ERROR_MESSAGE_START > > "ERROR!!!" > "Are you sure you wanted to declare x as an atom and not > really an integer instead? Or maybe you wanted to declare > it as a sequence and use only the first element for now so > that you can add elements later? > I'll hault your program now so you can think about it. > Oh, but one last thing: > If you decide that you really wanted to declare it as atom, > then i'll stop your program again anyway and ask you again." > > ERROR_MESSAGE_END > > <chuckles a little> > Whooaa! This is WAY off the mark. You have presented a situation that no- one is complaining about, proceed to show that its a silly situation then generalize from this that the namespace problem is the same sort of problem. But its not! The reason is that there is NO AMBIGUITY when somebody types atom x x = 1 Because 'atom' is a superset of integer, and this is quite acceptable and documented. If they had of written atom x x = "derek" then Eu detects an anomoly. The namespace issue is one of resolving an ambiguity. How can this come about??? Chris Bensler writes a library called 'clib.e' that contains a global routine called peek_string(). Derek writes a library called tk_mem.e that contains a global routine called peek_string() and includes that library in win32lib.e. When other people use either Chris' or Derek's peek_string() there is no problems. Its ONLY when somebody includes these clib.e and win32lib.e that problems can arise - through no fault of the person that combined them. The "invisible" global: qualifier is not going to help that one. -- cheers, Derek Parnell
9. Re: A Problem with v2.4 (for Rob)
- Posted by Juergen Luethje <j.lue at gmx.de> May 19, 2003
- 411 views
Hello Jim, you wrote: > In my namespace parser, when looking for "DoSomething", it would first look > at the local routines, then the global ones. If still no match, then it would > look at the namespaces, one-by-one, (in the order they were created) until it > found a match. If no match was found then it raised an error. > > Note that my parser didn't raise an error if there were _2_ DoSomeThing's, > since > it stopped after it had found _1_. > > That is arguably a flaw, but perhaps not. All this namespace stuff is quite hairy (at least for my brain 1.0 ). If there was a naming conflict because of 2 or more routines or variables with the same name in the same scope, I'd like the interpreter to raise an error rather than ignore all but the one it found first, for the sake of safety. > (I'm hinting at how the RDS version of namespaces could be improved, btw, > not at getting more people to use my namespace parser, in case you didn't get > that I got it. > ... my parser was designed for Eu 2.2, pre-namespaces.) > > jbrown > > On Sun, May 18, 2003 at 06:57:52PM +0200, Juergen Luethje wrote: <big snip> >> But using >> include file1.e >> include file2.e as i2 >> include file3.e as i3 >> >> should work, because any file has an unambiguous namespace. file1.e has >> the namespace "" which is not nothing. Eu IMHO should be able to handle >> that. My point is, that -- from a logical point of view -- here is no naming conflict at all, and I wish that this fact would be realized by Euphoria. Best regards, Juergen -- /"\ ASCII ribbon campain | |\ _,,,---,,_ \ / against HTML in | /,`.-'`' -. ;-;;,_ X e-mail and news, | |,4- ) )-,_..;\ ( `'-' / \ and unneeded MIME | '---''(_/--' `-'\_)
10. Re: A Problem with v2.4 (for Rob)
- Posted by Derek Parnell <ddparnell at bigpond.com> May 20, 2003
- 418 views
On Tue, 20 May 2003 00:37:21 +0000, Al Getz <Xaxo at aol.com> wrote: [snip] > > > Whooaaaa!! Derek, dont get so carried away! > It was merely an example to show that a language cant have > error handlers for everything because some things must be > explicitly stated. Sorry, I didn't get it. Still don't, too. > Also, remember that issue i said a while back that i didnt > want to mention because it would 'cloud' the current issue? > Well now that you brought it out, we have to deal with that > too. > > The reason you cant include two lib's that dont use namespace > qualifiers even with in invisible 'global:' prefix is because > DoSomething() in Henries lib is the same name as > DoSomething() > in Marges lib. > > So, that means you cant include BOTH Henries lib AND > Marges lib, right? Wrong. You can include both libraries. Try it. > BUT............. You can't refer to the common global name without at least one having a namespace qualifier. > You still *CAN* > include *EITHER* of the two libraries, and not run into a problem, > which is something you *CANT* do *NOW*!!! That does not make sense to me. Sorry. I'm not sure what you mean. > Since being able to include ONE library that doesnt have ns qualifiers is > better then not being able to include ANY (or ZERO) libraries, the > 'invisible' global prefix idea is better then the current situation. > In other words: > > integer ONE,ZERO > ONE=1 > ZERO=0 > > if ONE>ZERO then > puts(1,"having a global prefix is better then not having it") > else > puts(1,"having a global prefix is not any better then not having it") > end if > Also, along the same lines of reasoning you could also say that: > x:DoSomething in Henries lib is the same as > x:DoSomething > in Marges lib too, > > which also means that at some point > some things will have to be renamed, but, again > using the invisible global prefix would solve > at least problems associated with 'one' of the files, > something that cant be done now. Sorry, but I have to disagree again. It is possible with the current Euphoria to do something to fix this situation. I know because I'm doing it. You see, the namespace concept is designed to help us manage global symbols, but the namespace itself is not global. This means that I can code in win32lib.e ... include clib.e as xx . . . s = xx:peek_string(a) and somebody else can code in their program ... include win32lib.e include magiclib.e as xx . . . x = xx:magic_rtn() and there is now two independant namespaces called 'xx' that do not know about each other. This simply means that I can use any namespace ID I like inside win32lib and it will NOT clash with anybody else's IDs if they include win32lib.e > You will note that it is *not possible* to solve > the problem of two lib's included at the same time > if they use the same names like DoSomething() > and have been included in a third file, without > renaming something somewhere. > When two libs occur like this it's the responsibility > of the programmer to do some renaming. If we are using the current Euphoria then either the coder that is combining libraries will have to do some changes to the library code, or get the original authors to change their libraries. > The global prefix idea at least handles the case when > you are only including one lib that also includes files > that dont use namespaces, but it's still better then nothing. But its still a change to Euphoria, and that is not likely to happen in the near future (6-18 months). > > Now you see why i didnt want to cloud the issue earlier? No. > Take care, and lighten up a little will ya?? Now you're starting to sound like my son -- cheers, Derek Parnell
11. Re: A Problem with v2.4 (for Rob)
- Posted by jbrown1050 at hotpop.com May 20, 2003
- 413 views
On Mon, May 19, 2003 at 04:45:50PM +0200, Juergen Luethje wrote: > > Hello Jim, you wrote: > > > In my namespace parser, when looking for "DoSomething", it would first look > > at the local routines, then the global ones. If still no match, then it > > would > > look at the namespaces, one-by-one, (in the order they were created) until > > it > > found a match. If no match was found then it raised an error. > > > > Note that my parser didn't raise an error if there were _2_ DoSomeThing's, > > since > > it stopped after it had found _1_. > > > > That is arguably a flaw, but perhaps not. > > All this namespace stuff is quite hairy (at least for my brain 1.0 ). > If there was a naming conflict because of 2 or more routines or > variables with the same name in the same scope, I'd like the interpreter > to raise an error rather than ignore all but the one it found first, for > the sake of safety. > A better approach, for the interactive preparser, would be to show all the routines in all the namespaces, and ask the user which one to use. For the interpreter (or noninteractive preparser), flag an error, and abort. I'd feel, tho, that the interpreter should flag a warning instead of an error. <snip> > > On Sun, May 18, 2003 at 06:57:52PM +0200, Juergen Luethje wrote: > > <big snip> > > >> But using > >> include file1.e > >> include file2.e as i2 > >> include file3.e as i3 > >> > >> should work, because any file has an unambiguous namespace. file1.e has > >> the namespace "" which is not nothing. Eu IMHO should be able to handle > >> that. > > My point is, that -- from a logical point of view -- here is no naming > conflict at all, and I wish that this fact would be realized by Euphoria. As do I. I did mention, that my namespace parser DOES recognize this fact ... we are in complete agreement on this part, it would seem. > > Best regards, > Juergen > > -- > /"\ ASCII ribbon campain | |\ _,,,---,,_ > \ / against HTML in | /,`.-'`' -. ;-;;,_ > X e-mail and news, | |,4- ) )-,_..;\ ( `'-' > / \ and unneeded MIME | '---''(_/--' `-'\_) > jbrown -- /"\ ASCII ribbon | http://www.geocities.com/jbrown1050/ \ / campain against | Linux User:190064 X HTML in e-mail and | Linux Machine:84163 /*\ news, and unneeded MIME |
12. Re: A Problem with v2.4 (for Rob)
- Posted by Juergen Luethje <j.lue at gmx.de> May 20, 2003
- 411 views
Hello Jim, you wrote: > On Mon, May 19, 2003 at 04:45:50PM +0200, Juergen Luethje wrote: >> >> Hello Jim, you wrote: >> >>> In my namespace parser, when looking for "DoSomething", it would first look >>> at the local routines, then the global ones. If still no match, then it >>> would >>> look at the namespaces, one-by-one, (in the order they were created) until >>> it >>> found a match. If no match was found then it raised an error. >>> >>> Note that my parser didn't raise an error if there were _2_ DoSomeThing's, >>> since >>> it stopped after it had found _1_. >>> >>> That is arguably a flaw, but perhaps not. >> >> All this namespace stuff is quite hairy (at least for my brain 1.0 ). >> If there was a naming conflict because of 2 or more routines or >> variables with the same name in the same scope, I'd like the interpreter >> to raise an error rather than ignore all but the one it found first, for >> the sake of safety. >> > > A better approach, for the interactive preparser, would be to show all the > routines in all the namespaces, and ask the user which one to use. That sounds nice. > For the interpreter (or noninteractive preparser), flag an error, and abort. > I'd feel, tho, that the interpreter should flag a warning instead of an error. > > <snip> >>> On Sun, May 18, 2003 at 06:57:52PM +0200, Juergen Luethje wrote: >> >> <big snip> >> >>>> But using >>>> include file1.e >>>> include file2.e as i2 >>>> include file3.e as i3 >>>> >>>> should work, because any file has an unambiguous namespace. file1.e has >>>> the namespace "" which is not nothing. Eu IMHO should be able to handle >>>> that. >> >> My point is, that -- from a logical point of view -- here is no naming >> conflict at all, and I wish that this fact would be realized by Euphoria. > > As do I. I did mention, that my namespace parser DOES recognize this fact ... I must have missed that, sorry! This namespace stuff is almost driving me crazy. > we are in complete agreement on this part, it would seem. > > jbrown Best regards, Juergen -- /"\ ASCII ribbon campain | Everything should be made as simple \ / against HTML in | as possible, but not simpler. X e-mail and news, | / \ and unneeded MIME | http://www.sfheart.com/einstein.html
13. Re: A Problem with v2.4 (for Rob)
- Posted by irvm at ellijay.com May 20, 2003
- 405 views
On Monday 19 May 2003 10:41 pm, Derek wrote: > If we are using the current Euphoria then either the coder that is > combining libraries will have to do some changes to the library code, o= r > get the original authors to change their libraries. Which was, I thought, what we were trying to avoid.=20 Changing someone else's libraries is error-prone and counter-productive.=20 Plus you now have to ship those modified libraries along with your progra= m, causing conflicts with other programs which may use the original unmodifi= ed=20 libraries. Then whenever the original author of the library changes/updates her code= ,=20 your program no longer works. Some solution! Add to that the fact that properly implemented namespacing could encourag= e=20 clearer, more modular coding, but the current solution fails to do this,=20 because you can't "pass on" namespaced variables via another include. I'm sorry, but I have tried very hard to find a practical use for namespa= cing=20 (as implemented) and I just can't.=20 Irv
14. Re: A Problem with v2.4 (for Rob)
- Posted by Derek Parnell <ddparnell at bigpond.com> May 20, 2003
- 418 views
----- Original Message ----- From: <irvm at ellijay.com> To: "EUforum" <EUforum at topica.com> Subject: Re: A Problem with v2.4 (for Rob) > > > On Monday 19 May 2003 10:41 pm, Derek wrote: > > > If we are using the current Euphoria then either the coder that is > > combining libraries will have to do some changes to the library code, or > > get the original authors to change their libraries. > > Which was, I thought, what we were trying to avoid. I assume you mean by this is that the rationale for namespaces was that we are trying to avoid the need to alter other people's code. > Changing someone else's libraries is error-prone and counter-productive. > Plus you now have to ship those modified libraries along with your program, > causing conflicts with other programs which may use the original unmodified > libraries. > Then whenever the original author of the library changes/updates her code, > your program no longer works. Some solution! Agreed. And that's why we are trying to avoid being forced to modify their code. > Add to that the fact that properly implemented namespacing could encourage > clearer, more modular coding, but the current solution fails to do this, > because you can't "pass on" namespaced variables via another include. Its only in the last few days that I've realized I've been thinking about Euphoria's namespace implementation the wrong way round. I too thought like you that a coder put in namespaces for others to use when needed. This is the idea of "passing on" namespaced identifiers. However, I now see namespaces as just a way for me to force Euphoria to use a specific global symbol rather than one that just happens to be in scope. But it only effects the code that I write. In other words, if I'm writing a file that *could* be included by somebody, I really should ensure that any global symbols I use that are contained in files that I include, then I should be prefixing them with a namespace qualifier. That way, Eu is forced to use the global(s) from the specific files I include and not get confused with the same name being defined in some file that I did not explicitly include. To summarize, "X:Y" tells Euphoria to ONLY look in the file I've given the namespace 'X', for the symbol 'Y' - and not to bother looking anywhere else. > I'm sorry, but I have tried very hard to find a practical use for namespacing > (as implemented) and I just can't. Even though currently its not perfect, its still better than nothing - just. ---------------- cheers, Derek Parnell
15. Re: A Problem with v2.4 (for Rob)
- Posted by Juergen Luethje <j.lue at gmx.de> May 20, 2003
- 405 views
Hello Derek, you wrote: <snip> > Its only in the last few days that I've realized I've been thinking about > Euphoria's namespace implementation the wrong way round. <snip> If even you -- being one of our gurus -- write that, what shall most of the other people here say? I think it's quite legitimate to say, that Euphoria's namespaces are far from simple. I estimate there may be a maximum of 10 people in the world, who actually understand, how they work. <not sure what kind of smiley to put here> Best regards, Juergen -- /"\ ASCII ribbon campain | Everything should be made as simple \ / against HTML in | as possible, but not simpler. X e-mail and news, | / \ and unneeded MIME | http://www.sfheart.com/einstein.html