[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New module system option :duplicates
From: |
Rob Browning |
Subject: |
Re: New module system option :duplicates |
Date: |
Mon, 10 Mar 2003 18:14:28 -0600 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) |
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
- Re: New module system option :duplicates, (continued)
Re: New module system option :duplicates, Mikael Djurfeldt, 2003/03/10
Re: New module system option :duplicates, Rob Browning, 2003/03/07