Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
Pete Lomax wrote:
>
> Fair enough. Actually I just realised that since you could rebuild my table
> from the parentage info, both approaches are equivalent, just doing the work
> needed in different places.
Yep.
> > IMHO, solve 95% of the possible namespace conflicts with 3rd party libs.
> Agreed.
>
> > Now, when a namespace identifier is used:
> >
> > If a symbol is not within the file (as specified by the namespace
> > identifier), *or its include tree* then it is ignored.
> Are you really saying (see also final comment) that if I code
> }}}
<eucode>
> include win32lib.ew as win32lib
> ...
> l=win32lib:length(x)
> </eucode>
{{{
> ie, length() [or some global from somewhere else] has nothing to do with
> win32lib,
> but you just ignore it and use the builtin? Seems misleading to me. I would
> replace "it is ignored" with "then an error results" in your statement.
Yes, I think that would be an error. The global has to be somewhere in the
include tree of win32lib (so all of the memory stuff, for instance, could
be accessed through the win32lib namespace).
> > I suppose that giving preference to a symbol in the namespaced file (as
> > opposed to files included by that file) would also work to solve the
> > dilemma.
> The point is that without such you cannot explicitly refer to the one in the
> namespaced file, whereas you can for sub-includes by re-including them.
Yep, it's a case I hadn't thought of, but obviously needs to be addressed.
> CChris wrote:
> > -- in file2.e
> > integer my_var
> > my_var=n_also_in_third
> > -- could produec an error, while
> > -- file1.e::n_also_in_third is obviously being targeted
> As Matt said, unqualified it is not "obviously" the one in file1.e.
> However, "include file1.e as file1" must allow file1:n_also_in_third to
> explicitly
> target one of the clashing globals (Eu has worked exactly like that since 2.3
> and possibly before). As above it would not work properly without a preference
> scheme, when you extend the namespace scope that is.
>
> 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?
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.
> 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).
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.
> > 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.
Matt
|
Not Categorized, Please Help
|
|
