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
|
Not Categorized, Please Help
|
|
