Re: New module system option :duplicates

[Mikael Djurfeldt]

Greg Troxel <address@hidden> writes:

> That merging independent implementations works is either an
> accident, or the result of the special case of non-overlapping
> specifiers.

Still, I'm very curious how this plays out in practise.

Your argument can be made regarding the old goops implementation when
two different modules specializes the same imported GF.  Yet, with
disciplined use (see Kiczales paper; I've tried to follow those rules
in my own implementations), it appears to me that this works well in
practise.

And, again, :merge-accessors should be completely safe to use.

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

I think you're missing something here.  If the draw method for
<picture>:s hasn't been added to the generic function draw in
(graphics object), that module can't redraw the display.

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

Yes.  I think there is such a facility in Dylan.  We could maybe use
something similar.

M