Re: New module system option :duplicates

[Mikael Djurfeldt]

Mikael Djurfeldt <address@hidden> writes:

> 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.
>
> 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).
>
> 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).

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.

Note though, that there are many cases where we can't do that: We are
often in the position that we simply want to re-use eisting packages.