Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
CChris wrote:
>
> Matt Lewis wrote:
> >
> >
> > 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.
Yes, but what about those two libraries. One will have been included in
the main app after the other. Did the author use namespaces for everything
in his library? The first included library has polluted the namespace.
How does the second library manage to deconflict the 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.
In a perfect world, this would be done. And I agree that this isn't, in
and of itself, a deal breaker. I am saying that it's creating another
way to create bugs. How would the author know that he'd missed something?
That his library causes problems with some other piece of code that hasn't
even been written yet?
The end result is that the users of the library are going to have to do
extra work (by effectively editing the code of the library) to use this
library, which is exactly what I'm trying to avoid.
A negative list may reduce the chances of having to go in and edit, but
it does not solve the problem. It does, however drive up the complexity
of the code.
>
> > 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".
This really baffles me. You have a file which uses symbols in another file.
If that other file is not present, then it won't work. You're saying that
it's unintuitive to include that file with the symbols you depend upon?
> 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.
Well, if you're honestly trying to solve the namespace/third party conflict
problem then I'd agree with you, and I'd go farther to say that your
approach is deeply flawed.
> > 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.
>
> 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.
You still haven't answered the main issue here. How does this solve two
third party library conflicts? I'll admit that I simply may not understand
your solution well enough, and maybe your examples will clear this up,
but you seem to be avoiding the question by saying, effectively, that
your solution reduces the number of global symbols, so probabilistically,
the chance of a conflict is reduced.
I agree with you on that point. But your solution doesn't solve, AFAICT,
the conflicts themselves. So I'll use your terminology:
How would your approach resolve conflicts between two interface symbols
conflicting in two third party libraries. The conflict exists because
the libraries (not just user code) use those interface symbols.
Therefore, simply having a program like:
-- myapp.ex
include libMatt.e
include libCChris.e
...causes an error somewhere inside of libCChris.e, because one of its
interface symbols conflicts with an interface symbol in libMatt.e.
What would we need to do to make sure that this situation doesn't occur.
And what tools does the library programmer have to help him?
Matt
|
Not Categorized, Please Help
|
|
