Re: Enhancements to the include system
Pete Lomax wrote:
>
> Chris Bensler wrote:
> >
> > Pete: I didn't see your description of the implementation for Positive.
> > Can you reiterate the concept or point me?
> >
> Rather than hand you a solution on a plate (fairly obviously it is not
> easy to rip some code out of one compiler and stuff it into another),
> the point is more that this can be solved in the spirit of Euphoria,
> without any strange voodoo.
>
> First, to recap, there are two associated problems:
> }}}
<eucode>
> include win32lib.ew as w32
> w32:getOpenFileName()
> </eucode>
{{{
> is invalid in Eu because getOpenFileName() is defined in w32file.ew, and
>
> Derek's infamous alice/bob/chris/diane example, which is (in eric.exw):
> }}}
<eucode>
> include bob.e
> include alice.e
> global constant name = "Alice"
> <end of alice.e>
> if name!="Alice" then ?9/0 end if
> <end of bob.e>
> include diane.e
> include chris.e
> global constant name = "Chris"
> <end of chris.e>
> if name!="Chris" then ?9/0 end if -- [**]
> <end of diane.e>
> <end of eric.exw>
> </eucode>
{{{
>
> The point is that diane.e works for eric exactly the same as it did
> when diane created it, rather than crash over a missing namespace
> qualifier at [**]. If eric.exw itself referenced name, then you'd
> get the 'qualifier needed' message, but within diane.e, name gets
> automatically resolved to the one in chris.e because diane.e
> included that file (and did not include alice.e).
>
> It no longer matters that diane.e can "see" globals defined in alice.e
> as any defined by it's own includes take automatic preference.
>
> What I actually wrote (admittedly I thought I'd gone into more detail)
> was, mainly in respose to the first problem:
> 1] Or use Positive, if I ever get round to a new release, which
> handles nested sub-includes, provided, obviously, that there is only
> one valid instance of the global in that include "sub-tree". Anyone
> can see how it works & use any source found to fix this bug in 3.0.0.
> FWIW, relevant code is in psym.e, in functions InTable() and
> makeScanTable(), and use of variable abort_set, though it'll all be
> very different in eu.ex. I should perhaps also admit that Positive's
> routine_id does not (yet) do anything similar with namespaces.
>
> Feel free to ask me any questions about what you find.
> Regards,
> Pete
Ok, from what I understand there is no change in syntax. Just that when a
collision is encountered, the most closely 'related' definition is used to
resolve?
Well I do like that idea, it makes sense but it still only seems to cover a
portion of the problem. Globals will continue to be abused, namespacing just
hides the problem.
None the less, I think that it would be a good compliment to Eu's namespacing
system, even if it doesn't address the global contamination issue at all.
Personally, I'm interested in a solution that directly addresses the nessecity
to use globals in the first place. If we can reduce the need for globals, we will
put a much larger dent in the problem than by simply combatting the
contamination.
My thinking is long term..
In 5 or 10 or however many years, if or when eu has 100 or 1000x as many
programmers, will a namespace solution be sufficient to deal with global
contamination and still allow people to share code freely without alot of
conflict hassles? Don't get me wrong, I don't think we will ever eliminate global
contamination, but it can be hugely reduced.
The implementation you suggest is I think the only one I've heard which I would
agree should be implemented. It's not going to paint eu into a corner. I don't
see it interfering with future compatability and it's transparent. I still don't
think it actually addresses the issue though, just deals with it.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria
|
Not Categorized, Please Help
|
|
