From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: New module system option :duplicates Date: Tue, 11 Mar 2003 15:47:31 +0100 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> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047394135 10183 80.91.224.249 (11 Mar 2003 14:48:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 11 Mar 2003 14:48:55 +0000 (UTC) Cc: Rob Browning Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 11 15:48:52 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 18sl3k-0002dj-00 for ; Tue, 11 Mar 2003 15:48:52 +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 18sl4H-0000w5-00 for guile-devel@m.gmane.org; Tue, 11 Mar 2003 09:49:25 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18sl32-00008k-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 09:48:08 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18sl2W-0008Ix-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 09:47:37 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18sl2O-0008BG-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 09:47:29 -0500 Original-Received: from barbara.blakulla.net ([213.212.21.238] helo=linnaeus) by kvast.blakulla.net with esmtp (Exim 3.36 #1 (Debian)) id 18sl2K-0002zA-00; Tue, 11 Mar 2003 15:47:24 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18sl2R-0000vk-00; Tue, 11 Mar 2003 15:47:31 +0100 Original-To: Greg Troxel In-Reply-To: (Greg Troxel's message of "11 Mar 2003 09:29:28 -0500") User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 Original-cc: guile-devel@gnu.org Original-cc: djurfeldt@nada.kth.se 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:2068 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2068 Greg Troxel 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 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. I think you're missing something here. If the draw method for :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 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel