Re: Namespace (Is that your final answer?)
- Posted by DanMoyer at PRODIGY.NET
Jun 26, 2001
Irv,
The thing I like about your idea (and your explanation of it) is that I
think I can *understand* it, and it's almost as important that a namespace
solution be understandable and easy to use as it is that it be effective and
retroactive.
Dan Moyer
----- Original Message -----
From: "Irv Mullins"
>
> I'm pretty sure that Rob would like any namespace
> solution to apply retroactively, so that all the hundreds
> of user-contributions in the archives would all happily
> co-exist. No one wants to re-write all of those. Just
> testing all combinations would be a daunting task,
> one I estimate would take eternity plus two weeks,
> given that you'd have to start over every time a file
> was added or changed.
>
> To arrive at a workable solution, we have to first agree that
> ALL existing code is for practical purposes "off limits"
> to our own modifications. Why? Because:
>
> 1. It might be shrouded
> 2. It may be too complex for us to fix.
> 3. 'Fixing' something might break other packages that
> depend upon the one we're 'fixing'.
> 4. Our fix would have to be made part of the 'official'
> release, or next time the package was updated by
> the original author, our 'fix' would disappear.
> 5. There would be a proliferation of different non-
> interchangeable versions of every package.
>
> IOW, we shouldn't break other peoples' code just to
> make our sorry program work.
>
> So, if ALL existing library code is off limits, just what
> DO we have control over? Our code, obviously.
> What does our code do that could help? It "includes"
> these other packages, either directly, or indirectly.
>
> How can this help? Let's look at what happens now
> when I include file.a and file.b into my program.
> File.a and file.b were written by two different people.
> They didn't test them together, so both files make use
> of commonly used variables (x , y, or pi, for example).
>
> It won't run. How do I know? The interpreter TELLS me so.
> Here's the message:
> file.b:1
> attempt to redefine pi
> global integer x, pi
>
> Even if the include files are shrouded and scrambled,
> Euphoria still tells me the problem:
> file.bs:4
> attempt to redefine pi
> <scrambled code>
> ^
> OK, there's enough info here to tell me what's wrong, but
> I can't do anything about it - remember, ALL library code
> is considered off limits, for the reasons given earlier.
>
> I can't do anything, but Euphoria can - without even
> touching the source code. How? By simply changing
> the INTERNAL representation of the variables, following
> some simple rules:
>
> 1. Where a variable IS declared in this file, (file.b)
<snip>
|
Not Categorized, Please Help
|
|
