Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
Matt Lewis wrote:
>
> CChris wrote:
> >
> > It looks like you are concerned with other types of clashs than I, but my
> > solution
> > also handles "yours". Also, I may be more concerned about what happens when
> > a library changes: the issues are subtly different, since they concern code
> > you didn't write and ideally should not modify. I don't see that your
> > solution
> > helps much there - again, I have to read a complete description.
>
> I agree that my solution doesn't really deal with the encapsulation issue.
> That's not the point, and I don't believe that your solution really solves
> the issues at hand. The point is to fix the problem of using multiple
> libraries and having them conflict with each other. If two libraries
> export the same symbols, you still have the same problem.
>
If your application includes two libs which export the same identifier, it has
to explicitly choose one of them, using the current namespace system. At least,
internal (ie global, but not interface) symbols won't be seen, just interface
symbols.
> What happens when the library maintainer makes some changes, and the
> packaging directives don't keep up?
>
The maintainer usually tests his lib, and specially the new functionalities, and
something won't work right, which he should fix before shipping.
If the directives are in some custom wrapper you wrote, then it is your call to
keep the wrapper up to date, since you wrote it. Or to ship an update for your
application, so that an user can use the new version of the lib.
If the packaging uses a negative list, ie a list of internal symbols, then
adding more exported symbols requires no update at all.
> Also, your solution seems to me to be overly complex, and difficult to
> maintain. When we get to encapsulation, I think I'd prefer something
> along the lines of an import vs include, where the globals "imported"
> don't go beyond the file that imported them. This way, if you need to
> keep stuff hidden, just import it. If you want to expose things, either
> put it in the main include, or use the standard include directive.
>
> It's possible that I just don't understand your proposal sufficiently.
> Please submit a modified set of files to demonstrate how you'd modify
> v3.1 to handle these files. The benefit of my proposal is that there is
> absolutely no new syntax, and it does it in an intuitively straightforward
> manner.
>
Huh? It does work for some obvious cases, but explicitly inluding a parent file,
for example, is far from anything I'd call "intuitive or straightforward".
I'll have to post the files indeed. As I noted earlier, this may take some time
because of RL fiercely catching up these days. But this is the way to go. Also, I
didn't try adjusting the runtime lookup functions accordingly yet.
> I'm not really interested (in this discussion) to hear about how your
> solution encapsulates symbols. I'm interested in how we deal with
> multiple files that expose duplicate symbols, whether the original
> author wants them to be exposed or just used internally. Accept that
> the symbols are exposed to the program.
We obviously have different approaches.
>
> It seems that your method puts a larger burden onto the programmer to
> resolve conflicts. My goal is to take what's already there (all
> those include statements) and to make full use of the information that
> they impart.
>
> Matt
The only burden is to disambiguate between interface and non interface symbols.
It is not a new task for programmer, since the docs he wrote usually do this
already.
CChris
|
Not Categorized, Please Help
|
|
