Re: New module system option :duplicates

[Rob Browning]

Mikael Djurfeldt <address@hidden> 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, and if so, is that to be expected/OK?
i.e. does this just fall under the "well don't do that then" category?

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

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4