From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: New module system option :duplicates Date: 11 Mar 2003 09:29:28 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87ptp3b5ak.fsf@zagadka.ping.de> <87el5jb3gp.fsf@zagadka.ping.de> <87zno7w1xk.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047393192 5549 80.91.224.249 (11 Mar 2003 14:33:12 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 11 Mar 2003 14:33:12 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 11 15:33:10 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18skne-0001MO-00 for ; Tue, 11 Mar 2003 15:32:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18sknI-0008C0-05 for guile-devel@m.gmane.org; Tue, 11 Mar 2003 09:31:52 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18skmE-0007ry-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 09:30:46 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18skln-0007aT-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 09:30:31 -0500 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18skl2-0006xA-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 09:29:32 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id F1A8D86B; Tue, 11 Mar 2003 09:29:28 -0500 (EST) Original-To: djurfeldt@nada.kth.se In-Reply-To: Original-Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Original-cc: Rob Browning Original-cc: Marius Vollmer X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2067 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2067 Thanks for the 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. OK - this is a sensible and realistic scenario. Now we're developing a module (graphics object picture) which provides the class which is a subclass of exported by (graphics object). Internally, objects store a from the (graphics paint) module. Therefore (draw picture) internally calls (draw bitmap). This works, because `draw' in (graphics object picture) is an which shares methods with draw in (graphics object) and draw in (graphics paint). The two draw methods were developed independently, and are thus in general not safe to merge. (graphics object picture) imports (graphics object) and subclasses it, and imports (graphics paint) and merely _uses_ it. So the draw method from (graphics paint) should be renamed to avoid the conflict. That merging independent implementations works is either an accident, or the result of the special case of non-overlapping specifiers. 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 on the list of visible objects. This may include our object, so it is essential that draw in (graphics object) shares the (draw ) method with draw in (graphics object picture). The draw GF is invoked on a , 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. If that draw method calls the renamed draw method that is the (graphics paint) GF, finding the specialized method, all is well. So, I don't see how the draw generic in (graphics object) needs to modified/extended at all; this would be the modularity violation that bothered me. Having draw be extended in (graphics object picture) is a bit bothersome, but much less so. A problem would arise if each defined draw on, say vectors or objects - really any specializers that are not disjoint. In multiple inheritance cases where implementation is shared, then the GFs do probably need to be merged. But then the author of the module that inherits from both rightfully needs to grok the details of the underlying, so declaring that GF draw should be merged is a reasonable thing to put in the module declaration. And MI with interface only, the using module needs merged GFs. One issue is whether the functions to be merged are the 'same function' semantically or just have the same name. But in any case, I don't see why a module's GF should get any methods added to it when another module uses it. Sorry if I'm seeming difficult/dense - I'm trying hard to keep the module/goops orthogonality while not violating Schemely sensibilities. One of the things that makes me thing GFs should not be merged without explicit instruction is that for all other kinds of values merging can't happen. 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. 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. Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel