RE: A Problem with v2.4 (for Rob)#2
Hello there Derek,
I think you may have missed the point, which i'll try to clarify here.
You did, however, hint on something else that might also be a problem,
but im not sure i want to get into it right now because it might
cloud the first issue here.
Derek Parnell wrote:
>
>
> 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()
>
I could do this with Eu v2.0 by changeing ":" to "_" .
If you look closely at the
above code, you will notice that you changed two things:
1. the include statement from "include file.ew" to "include file.ew as
SE"
2. DoSomething() to SE:DoSomething()
But in the actual code you would have had to change 102 things because
there were 100 other existing functions also.
So, when you say "Explicitly tell Eu" what you really mean
is "rename", and once you say 'rename' havent you defeated
the purpose of having a namespace in the first place?
The reason for having a namespace is so you dont have to go
over someone elses code and rename every variable in the files
that clashes with yours.
If you dont agree on this, then i have 2073 include files i
can send you and you can 'explicitly tell Eu' in all the files
for every global and then send them back to me 
>
> 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
>
> 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.
>
>
This is what the two lines:
include thisfile.ew as wx
include thisfile.ew
was suppose to show the 'fix' for just in case any code gets broken.
I agree a warning would be better too.
WX:MyAtom
should refer only to the file that was included as WX,
which certainly makes sense.
MyAtom
would refer to only a global atom declared in another file.
Lets try to take a more careful look...
The main problem involves at least two sets of files, the
existing files and the new files. Since each set
can either use qualifiers or not use qualifiers,
we end up with 16 cases, which i believe can be
reduced to the two most important ones:
1. (Existing files uses Namespace Qualifiers) AND (New files do too)
2. (Existing files dont use Namespaces) AND (New files do use them)
Now we already know that case #1 probably works ok.
It's case #2 that is the biggest problem.
Note that if we assigned two values to indicate whether or not
the file ever was included with Namespace Prefixes we might choose these
two:
constant
HAS_PREFIX=1,
NO_PREFIX=0
and so the interpreter would always be able to tell the difference
between
DoSomething() --in existing code
and
MF:DoSomething() --a new procdure in the new code
Another way of stating the solution would be this:
1. For every global that appears in the file assign a provisional
namespace qualifier. For the sake of clarity here lets use 'guID'.
Now the function that first appears as 'DoSomething()' looks like
this:
guID:DoSomething()
except the prefix 'guID:' is implied, not visible to the programmer.
2. The next thing that could happen is the file with 'DoSomething()'
in it gets included with 'include file.ew'. In this case, for all
globals that appear in the file each one keeps it's original
provisional prefix of 'guID:' .
Alternately, the file might get included with
'include file.ew as XP'
in which case the provisional prefix gets replaced with "XP:" .
This should be very easy to implement.
Now, looking back at the original code, the function
"DoSomething()"
calls the original existing function as expected because
it already has a prefix and that prefix matches the original
codes prefix (even though invisible to the programmer),
and the new function
"MF:DoSomething()"
calls the new code as expected.
BTW, the provisional globally unique identifier could be
choosen to be something like "EuXyZ" and conveyed to
programmers as a reserved keyword for prefixes so as
not to use for your new file prefixes. We wouldnt want
to take up any name that could be useful in an actual
program such as "GuID".
I hope this clears up this issue as i would really like to see
this get resolved very soon.
Take care for now,
Al
|
Not Categorized, Please Help
|
|
