Brent Pinkney <b...@4dst.com> writes:
> How does that work in an environment where you are using third party
> libraries, lice srfi, ice-9, guile-lib, etc as well as your own code.
Okay, I have a guess about what you meant here. Suppose two
independently developed modules add methods to generics with the same
name. How can they arrange to export the generic from a single module?
This is the heart of the issue.
The problem is, how does Guile know that these two generics with the
same name *should* be merged together? Maybe they have completely
different semantics.
For example, suppose a curses-based display module defines a "draw"
generic function, and adds methods to it for the standard Scheme data
types such as strings and lists. Now suppose an unrelated OpenGL
display module defines its own "draw" generic function, and adds methods
for the same Scheme data types.
It would obviously be bad if Guile assumed that these were the same
generic function, just because they have the same name. And yet
avoiding such collisions would require giving generic functions long
names, and the crossing one's fingers and hoping that no one else used
the same name, just like in the bad old days of Lisps based on
dynamically-scoped variables.
On the other hand, if you know that two generics from independently
developed modules should be merged, then you can make that happen using
the 'merge-generics' stuff. However, it's best to avoid this way of
doing things when feasible.
In particular, the practice of letting each module in your project
automatically define fresh generics (and then merging these generics
together while importing the modules) has a serious problem: it means
that each module ends up with generics that only work on the classes
that it *directly* imported. In many cases this is not sufficient.
Mark
