Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
Matt Lewis wrote:
>
> Pete Lomax wrote:
> > I agree a global from the parent should override one from a grandparent but
> > agree with Matt that it should not override ones in the siblings.
> > Not quite sure where Matt stands on the first part.
>
> I think that 'the first part' is the global/parent/grandparent statement?
Yes. An example:
main.e
global Z
include libA.e
global Z
include libAmisc.e
if Z then
Once you take the view that libA works standalone and including it as part of a
larger app should not change that, then the unqualified reference to Z should
automatically resolve to the one in libA and ignore the one in main.e
IMO such a rule would help far more often than hinder, and not as if it is going
to break any existing code or anything.
> I'm not sure on that one. Alternately, your statement seems to logically
> follow the other facts, but there's something about it that isn't sitting
> right. I'll have to think about it some more, but I suspect that you're
> correct.
Perhaps the missing part is that "include third.e as third" also allows
third:n_also_in_third to explicitly target the other one of the clashing globals.
> > Matt Lewis wrote:
> > > Continuing my train of thought from the response to Pete, I guess a
> > > legitimate question to be asked would be whether we should let symbols in
> > > directly included files mask those from lower down in the tree? Assuming,
> > > of course, that no namespace identifier is used, and there is only one
> > > possible symbol.
> > Are you saying that in eric you would check bob&diane (directly included by
> > eric) as one level then alice&chris (included indirectly via bob&diane
> > respectively) as the next, which seems messy? The parent masks grandparent
> > seems
> > more useful. One of my guiding principles is: If it works standalone, it
> > should
> > work the same when you include it in the middle of an application.
>
> I'm not sure I follow the difference here. Maybe I'm thinking too much
> in terms of the way RTLookup is coded (and the symbol table is put
> together). I don't think there's any guarantee that you'll encounter
> symbols from one file before another, so you have to check all of them
> before deciding who masks whom (though I might be wrong about this).
Given that some of the sub-includes may in fact be re-includes, then yes,
following a hash chain may chance upon relevant entries in a completely
higgledy-piggledy fashion. I concede that treating bob&diane as one level and
alice&chris as one lower need not be any messier, still not seeing why you would
actually want to do that though. Got a practical example?
> I think some of my concern with the masking is that it's a new behavior
> for euphoria, and isn't always obvious. I think that if any globals from
> other files mask other globals from other files due to a parent/grandparent
> relationship, there should be at minimum a warning generated. I think
> it would be easy to get confused as to which symbol is resolved, and
> going on our merry way to destruction.
The obvious thing is to develop a set of test files. You can find the ones I
used at http://www.palacebuilders.pwp.blueyonder.co.uk/t05.zip which you may or
may not have already seen and may or may not find useful. The .exw files are the
actual tests (14 of), some of which are mind numbingly trivial.
Probably also a good ideal to develop a set of "fail" test files which should
generate the desired errors and warnings.
> > > I'm also starting to think that any symbol resolution from beyond the
> > > include tree should generate a warning.
> > Is this the same worry I had with "win32lib:length" above?
>
> I don't think so. Let's say you're developing myapp.exw, and it includes
> win32lib. It also includes myapp.ew, which does not include win32lib,
> but calls win32lib routines. As long as win32lib was included before
> myapp.ew, then this will work, but since you're depending on symbols that
> you've never explicitly included into myapp.ew, I believe that a warning
> should be generated.
I'm not convinced. If you can make myapp:closeWindow() work in this case without
introducing other problems then fair do's, but I still think it should just be an
error (which goes away if you put "include win32lib.ew" inside myapp.ew).
Regards,
Pete
|
Not Categorized, Please Help
|
|
