Re: New module system option :duplicates

[Mikael Djurfeldt <djurfeldt@nada.kth.se>]

Rob Browning <rlb@defaultvalue.org> writes:

> Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:
>
>>> Why would x in (math 2D-vectors) be able to see the methods of x in
>>> (my-module)?  Isn't that a violation of modularity?  The reverse I
>>> understand.
>>
>> Think about dynamic method dispatch.  A `paint' method in a generic
>> graphics package need to see subclasses provided by modules importing
>> the generic package.
>
> Hmm.  Though I haven't thought carefully about it yet, that still
> feels like somewhat a modularity violation to me.
>
> Say you have a working module called (math-frob) that defines/uses
> some generic-function, say "do-fancy-+", that at the time (foo random)
> was designed only had a method for ((x <number>) (y <number>))
> arguments.
>
> Then say someone writes module (bar) that defines do-fancy-+ for ((x
> <integer>) (y <integer>)) arguments, but does it in a way that's not
> compatibile with the do-fancy-+ usages in (foo random).  If someone
> does
>
>   (use-modules (foo random))
>   (use-modules (bar))
>
> then is (foo random) now broken

It is not.  Since do-fancy-+ in (bar) is neither descendant nor
ancestor of do-fancy-+ in (foo random), do-fancy-+ in (foo random)
won't share methods with do-fancy-+ in (bar), so both functions will
continue to work unaffectedly.

> i.e. does this just fall under the "well don't do that then" category?

The driving need behind my suggested automatic merging of generics is
to enable different imported modules to tell how to do the "x"-thing
on their provided new type of object.  In particular, it enables using
shorter names for the multitude of object accessors exported from
modules.

It is probably an error to import two generic functions which do
different things on the same type of object, and we may choose to
detect this error during the merge.  One could, for example, have
certain requirements on the disjointedness of the inheritance
hierarchies of the classes which the merged functions are specialized
to.

Still, this is a good reason to use the programming style suggested by
Marius: to explicitly state which functions should be merged so that
we have the guarantee that the merge is intentional.  I have now
provided the facilities for using Marius' style:
`define-extended-generics' and the :use-modules option :prefix.

However, I'd very much like to try out this "automatic merge"
programming style to see how it works out in practise in large
projects.  This is why I have provided it as a user option---the
default behavior is not to merge generic functions automatically.

If it turns out that implicit merge of generics causes lots of bugs,
one possible alternativ is to provide :merge-accessors which only
automatically merges object accessors.

> (I still need to go look and see how CLOS handles such a situation...)

The following paper is a good read:

http://kvast.blakulla.net/mdj/kiczales92.pdf

M


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