Re: New module system option :duplicates

[Greg Troxel <gdt@ir.bbn.com>]

Thanks for the example.

  An object-oriented graphics package (graphics object) exports the GF
  `draw'.  So does the pixel-oriented graphics package (graphics paint).
  These two packages are developed independently by different developers
  but use a common representation of the output device, provided by a
  third module.

OK - this is a sensible and realistic scenario.

  Now we're developing a module (graphics object picture) which provides
  the class <picture> which is a subclass of <graphics-object> exported
  by (graphics object).  Internally, <picture> objects store a <bitmap>
  from the (graphics paint) module.  Therefore (draw picture) internally
  calls (draw bitmap).  This works, because `draw' in (graphics object
  picture) is an <extended-generic> which shares methods with draw in
  (graphics object) and draw in (graphics paint).

The two draw methods were developed independently, and are thus in
general not safe to merge.  (graphics object picture) imports
(graphics object) and subclasses it, and imports (graphics paint) and
merely _uses_ it.  So the draw method from (graphics paint) should be
renamed to avoid the conflict.  That merging independent
implementations works is either an accident, or the result of the
special case of non-overlapping specifiers.

  However, when the X window is redisplayed and all objects need to be
  redrawn, the update function in the (graphics object) package calls
  `draw' on each <graphics-object> on the list of visible objects.  This
  may include our <picture> object, so it is essential that draw in
  (graphics object) shares the (draw <picture>) method with draw in
  (graphics object picture).

The draw GF is invoked on a <picture>, which finds the method
specialized to (graphics object picture).  This method was defined in
(graphics object picture), and thus there is no need for the (g o)
draw definition to find the draw of (graphics picture).  This method
is in the new module.  If that draw method calls the renamed draw
method that is the (graphics paint) GF, finding the specialized
method, all is well.

So, I don't see how the draw generic in (graphics object) needs to
modified/extended at all; this would be the modularity violation that
bothered me.  Having draw be extended in (graphics object picture)
is a bit bothersome, but much less so.  A problem would arise if each
defined draw on, say vectors or objects - really any specializers that
are not disjoint.

In multiple inheritance cases where implementation is shared, then the
GFs do probably need to be merged.  But then the author of the module
that inherits from both rightfully needs to grok the details of the
underlying, so declaring that GF draw should be merged is a reasonable
thing to put in the module declaration.  And MI with interface only,
the using module needs merged GFs.

One issue is whether the functions to be merged are the 'same
function' semantically or just have the same name.   But in any case,
I don't see why a module's GF should get any methods added to it when
another module uses it.

Sorry if I'm seeming difficult/dense - I'm trying hard to keep the
module/goops orthogonality while not violating Schemely sensibilities.
One of the things that makes me thing GFs should not be merged without
explicit instruction is that for all other kinds of values merging
can't happen.

  Let me add that this is a quite bad example.  In the case above, the
  natural design would be to have the module representing the output
  device export `draw' and let both (graphics object) and (graphics
  paint) add their methods on it.

This raises an interesting issue.  There is a difference between
extending a defined interface and using a modules provided
abstractions.  In your restructured example, the output device exports
draw, and presumably the low level functions that actualy let you draw
bits on the screen.
It would be nice for that export of draw to be marked in such a way
that the exported GF may be modified by adding methods.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel