[Prev][Next][Index][Thread]
Re: A basic question: defining modules and libraries
On Tue, 28 Mar 2000, Eric Gouriou wrote:
> Hugh Greene wrote:
> > ... As long as your particular set of client libraries can easily be
> > directed to the right set of used libraries ... who cares what they're
> > called?!
>
> I think this is fine to have this mapping in the project configuration,
> as in FD. However it does not solve the name collision risks [e.g.,
> having] com.vendorA.SQL and com.vendorB.SQL (as a convention)
> would solve this.
>
> > I don't think a language extension is needed to avoid name clashes,
> > rather an extension to the implementations. FD currently lets you
> > pick which project file supplies a library ... but it could do with a
> > more sophisticated system.
>
> I do not fully understand what you are trying to solve here.
> Would this solve my hypothetical SQL libraries clashes ?
Sorry, I should have explained the relevant part of my idea of "more
sophisticated". I was thinking that, just as you can rename modules and
bindings on import, how about being able to rename libraries on
(implementation-defined) lookup? I'm imagining bending the rules a bit
and allowing one library to "use com.vendorA.sql;" and have the mapping
point it to "C:\Vendor A\SQL\sql.lid" and, crucially, *override* the
library name defined in that LID (and the "define library"). You'd
probably want the mapping to explicitly state "sql is renamed to
com.vendorA.sql", allowing you to check the non-overridden library name,
in case you accidentally point it at the wrong LID file.
I think this would also avoid Dustin Voss's issue with real-world names
being unstable. [Very good point, though I have to say "Yeah, right, and
software is so stable by comparison!" ;-)] It gives individual
(groups of) developers the power to resolve clashes locally for themselves
and still use natural, informal language to disambiguate things in, say,
email communication.
> > ... versioning [is] harder than it seems. [We could use pointers]
> > to some "best practice".
>
> HP-UX shared library versioning is explained here [...]
Thanks -- I'll read those eventually :-)
References: