Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
CChris wrote:
>
> Matt Lewis wrote:
> >
> > No, it doesn't climb back up the tree. I can see the logic of it, but I'm
> > not sure I agree with this. Is it really that common? I know that I've
> > occasionally been guilty of this.
> >
>
> How do you have reliable two way communication between a server and a client
> then? So it is common as soon as your lib/app is not organised in a pyramidal
> way. By "reliable" I mean, not disrupted by a third party file included
> alongside
> a large library.
You've lost me here.
> > From the perspective of file2.e, it's not obvious that the correct
> > resolution
> > should be from file1.e.
>
> Huh?
> A parent/ancestor is a more likely target than a cousin, don't you think?
I think you've missed my point. I agree that the parent is more likely,
but it's still ambiguous. file2.e has a dependency that it doesn't make
clear. The symbol could be from anywhere. Now, if it added an include
to its parent, then it would be much clearer. A better solution might
be to move those symbols to a separate file that both file1.e and file2.e
could include. This would make things less ambiguous for both the
parser and the coder.
> > I think it might be better to give an error in
> > this case. The resolution would be to include the file explicitly.
>
> Which means file2.e should include file1.e, even though file1.e includes
> file2.e?
> It makes sense, but will such a sea change - allowing circular includes - be
> accepted? I would.
They are currently accepted. There is no change, except that we still
need a mechanism for allowing symbols in a direct include to mask those
of an indirect include.
Matt
|
Not Categorized, Please Help
|
|
