1. Namespace vote
Just my 2.41 yen:
I think the format
include myfile.e as lib1
include herfile.e
include hisfile.e as lib1
along with conditional includes would make the most sense. Multiple =
files sharing the same namespace is allowable as long as the two files do =
not have any symbol conflicts. Sharing a namespace, especially a blank =
namespace, seems the easiest way to avoid breaking code. And it's an =
elegant solution. If both files contain function abs(), then the following =
usage should apply (same as with variables & constants):
x =3D abs(y) -- uses the function in herfile.e
x =3D :abs(y) -- blank namespace also uses herfile.e
x =3D lib1:abs(y) -- uses the function in myfile.e
x =3D bil9:abs(y) -- fails because there is no such namespace.
function abs(object y) -- fails because the blank namespace is already =
taken
-- with that function
Anyway, just my thoughts for the day.
2. Re: Namespace vote
On Tuesday 26 June 2001 09:36, Sabal.Mike at notations.com wrote:
> Just my 2.41 yen:
>
> I think the format
>
> include myfile.e as lib1
> include herfile.e
> include hisfile.e as lib1
>
> along with conditional includes would make the most sense. Multiple
> files sharing the same namespace is allowable as long as the two files do
> not have any symbol conflicts. Sharing a namespace, especially a blank
> namespace, seems the easiest way to avoid breaking code. And it's an
> elegant solution. If both files contain function abs(), then the following
> usage should apply (same as with variables & constants):
>
> x = abs(y) -- uses the function in herfile.e
> x = :abs(y) -- blank namespace also uses herfile.e
> x = lib1:abs(y) -- uses the function in myfile.e
> x = bil9:abs(y) -- fails because there is no such namespace.
>
> function abs(object y) -- fails because the blank namespace is already
> taken -- with that function
This is good, but I think it might be necessary to disallow
the plain "include hisfile" syntax when writing a library.
Suppose Joe writes a library which uses herfile and
hisfile:
If herfile is updated, and new routines/variables added,
some of those might conflict with routines Joe had already
written, or with routines in other plain "include" files that
Joe had included.
Joe might not be available or in the mood to re-write
his library (to add the qualifications) and for reasons
already discussed, it's not a good idea to make the
changes yourself (assuming it were possible)
Nor would this fix the problem of existing library conflicts,
since none of them use namespacing. It seems a shame
to have to re-invent all that code.
Regards,
Irv
3. Re: Namespace vote
We have to allow the plain "include hisfile" syntax to avoid breaking =
existing code. Besides that, Euphoria really doesn't know the difference =
between a program or a library or an unshared include (like a bitmap =
constant file). What's good for the goose has to be good for the gander. =
=20
<flame suit on>
I don't think we can effectively add namespace improvements going =
backwards. Only new programs would benefit from the namespace mod. If =
file.c includes file .a and file.b and I include file.c in myprog.ex; and =
if there currently is a namespace issue, whatever happens now without =
namespaces must continue to happen within the context of a blank namespace.=
If the program breaks now, it should continue to break. If one scope or =
another has precedence, it should continue to do so. The worst thing that =
could happen is a program suddenly changing behavior because an updated =
interpreter was installed. Remember when the reverse() function was first =
added to Euphoria, users of existing versions of win32lib had to modify =
the library (removing the reverse function) to continue using the library. =
If I want to use two libraries that currently break when used together, I =
have to modify the library in any event. If I can namespace the libraries =
in my program to let them work together, perfect (this is a majority of =
cases). If each library includes other libraries that conflict, I will =
have to modify one or the other libraries, or I simply won't be able to =
use them together (no different from now, and a smaller percentage of =
cases). Anyway, I'll start ducking those flaming arrows 
.
Mike Sabal
>>> irvm at ellijay.com 06/26/01 11:27AM >>>
This is good, but I think it might be necessary to disallow=20
the plain "include hisfile" syntax when writing a library.
Nor would this fix the problem of existing library conflicts,=20
since none of them use namespacing. It seems a shame=20
to have to re-invent all that code.
Regards,
Irv
4. Re: Namespace vote
On Tuesday 26 June 2001 11:51, Sabal.Mike at notations.com wrote:
> We have to allow the plain "include hisfile" syntax to avoid breaking
> existing code. Besides that, Euphoria really doesn't know the difference
> between a program or a library or an unshared include (like a bitmap
> constant file). What's good for the goose has to be good for the gander.
Euphoria may not know, but I'll just bet the programmer does.
Anyway, if you run the code and nothing happens, it's a library;)
Come to think of it, Euphoria should be able to tell the difference,
also. Think about it.
> <flame suit on>
>
> I don't think we can effectively add namespace improvements going
> backwards. Only new programs would benefit from the namespace mod.
Then it's the wrong mod, and hardly worth Rob's time.
> If file.c includes file .a and file.b and I include file.c in myprog.ex; and
> if there currently is a namespace issue, whatever happens now without
> namespaces must continue to happen within the context of a blank namespace.
> If the program breaks now, it should continue to break.
What if it works now, but breaks next week?
That's the most common problem. If we want this to continue, why
bother with namespaces at all? We already have the behaviour we
want.
> If one scope or
> another has precedence, it should continue to do so. The worst thing that
> could happen is a program suddenly changing behavior because an updated
> interpreter was installed.
Don't you think that programs change behavior now, when one of the
include files is updated? Suddenly refusing to work any longer seems
like a change to me. (Is dead a behavior?)
Besides, there's been no talk of changing the runtime behavior of Euphoria -
just an improvement in the error detection., so that programs that won't run
now, may be coerced into running properly.
> Remember when the reverse() function was first
> added to Euphoria, users of existing versions of win32lib had to modify the
> library (removing the reverse function) to continue using the library.
Exactly proves my point - reverse() is a global function, so it clobbered
Win32Lib's version (or vise-versa). Win32Lib had been written without
namespacing, because there wasn't any. We need a solution that does
NOT require rewriting everything, including Win32Lib.
> If I want to use two libraries that currently break when used together,
> I have to modify the library in any event.
You do now, yes - and that's exactly what everybody has been complaining
about. You and I have no business modifying code which is someone else's
responsibility. Besides, why modify two perfectly good libraries?
It 'forks' the code base, and can even prevent you from taking advantage of
updates. Gotta track all the changes you made, add them back, and then
re-test everything to see that the updates don't interfere
with your changes, and that your changes haven't broken the updated file.
Are you willing to test your mods with each - no, make that
all - of the 800 or so programs on the website? Neither is the
original author. That is why Euphoria should be able to detect
collisions and then allow us to work around the problem.
Ideally, we should be able to accomplish this workaround in
our OWN code.
> If I can namespace the libraries in my
> program to let them work together, perfect (this is a majority of cases).
> If each library includes other libraries that conflict, I will have to
> modify one or the other libraries, or I simply won't be able to use them
> together (no different from now, and a smaller percentage of cases).
> Anyway, I'll start ducking those flaming arrows .
See note above. Modifying other people's libraries is one of the things
we're trying to avoid. Not using the excellent libraries other people have
produced is plain silly (and if Euphoria doesn't allow it, shame on Euphoria!)
Regards,
Irv
