symbol resolution (was:EuCOM : Attn Matt : String Return Value)
Matt Lewis wrote:
>
> Pete Lomax wrote:
> >
> > Matt Lewis wrote:
> > >
> > > Actually, namespaces will be inherited (and are inherited, for code at > >
> > > > head of the svn repository) in the next release. I typically run this
> > > code, which is probably why I haven't noticed the bug.
> >
> > Cool. How did you solve that in the end? In Positive I devised a set of
> > priority
> > tables, which is quite simple really but harder to explain, eg:
> >
> > -- fileno desc parents priorities
> > -- 1 inc7 {} {2,1,1,1,1,1}
> > -- 2 eric {1} {2,4,3,3,3,3}
> > -- 3 bob {2} {2,4,6,5}
>
> <snip>
>
> My technique is a bit different. I don't worry about priorities. Just the
> 'lineage' of each file. Basically, I record who got included by whom.
> Then, when doing a symbol lookup, if there are multiple matching global
> symbols, I have to do some work.
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.
> 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
include win32lib.ew as win32lib
...
l=win32lib:length(x)
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.
> 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.
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.
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 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?
Regards,
Pete
|
Not Categorized, Please Help
|
|
