Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
CChris wrote:
>
> Matt Lewis wrote:
> >
> > CChris wrote:
> > >
> > > 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.
> >
>
> Why include a file in a program?
> Reason #1: so that the including file can rely on routines, and less often
> variables,
> from the included file;
> Reason #2, often forgotten: so that the included file can benefit from
> services
> (data or routines) from the including file. By carefully choosing the
> placement
> of the include statement, the including file can control which global
> identifiers
> the included file can access.
>
> Now, if the including file also includes a third party file, and the latter
> has a symbol that clashes with one in the including file, then the _included_
> file will have its access to the clashing symbol in the including file
> disrupted.
>
> I hope my point about client/server is clearer now.
Yes. I would repeat what I said in the response to Pete. The 'client'
file should have an include statement to its parent to make clear that it
uses symbols in that file.
> > > > 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.
>
> Is the dependency to appear necessarily in file2?
Not sure exactly what your asking here, but I'll clarify my statement. By
dependency, I mean that file2 is using a symbol from file1. But the
problem is that file2 never includes file1, so it's implicit, and can
lead to ambiguity down the road, depending on how its used. I'd rather
throw a warning or an error than make assumptions that can lead to
subtle bugs.
> > 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.
>
> This is ok for variables in the including file, but not for routines, as they
> frequently access local symbols. If the routines that both file1 and file2
> would
> include are the only users of the locals they use in file1, then these locals
> can be moved to the new file, but this is a rather rare, favourable
> circumstance.
> Your scheme would increase the use of global symbols because of the unnatural,
> inconvenient splitting of files.
I agree, which is why I used the 'might' caveat. TIMTOWTDI.
> >
> > > > 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
>
> Currently, they are accepted, but ignored, as the target of the second include
> statement is already known from parser. The change is that, however, note
> would
> be taken of the inclusion attempt so that the included file can see symbols
> from the including file. And care is needed so that only the known symbols in
> the including file at the time it includes the included file are visible from
> it, not all global symbols. Or did I get anything wrong?
They are ignored, only inasmuch as they don't generate new code. In the
current code (note: not the released version, but the svn head) it will
have the effect of improving symbol resolution. It shouldn't break any
existing code, but should assist in resolving namespace conflicts (though
with the deficiencies previously mentioned in this thread).
Matt
|
Not Categorized, Please Help
|
|
