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 11:32:15 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <878yvrxhp1.fsf@raven.i.defaultvalue.org> <87adg2kbdn.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 1047378716 10790 80.91.224.249 (11 Mar 2003 10:31:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 11 Mar 2003 10:31:56 +0000 (UTC) Cc: djurfeldt@nada.kth.se Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 11 11:31:54 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 18sh34-0002nt-00 for ; Tue, 11 Mar 2003 11:31:54 +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 18sh3e-0003Gh-00 for guile-devel@m.gmane.org; Tue, 11 Mar 2003 05:32:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18sh3M-0003GY-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 05:32:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18sh3L-0003GM-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 05:32:11 -0500 Original-Received: from kvast.blakulla.net ([213.212.20.77]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18sh3K-0003GA-00 for guile-devel@gnu.org; Tue, 11 Mar 2003 05:32:10 -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 18sh3H-0002ZM-00; Tue, 11 Mar 2003 11:32:07 +0100 Original-Received: from mdj by linnaeus with local (Exim 3.36 #1 (Debian)) id 18sh3P-0004WJ-00; Tue, 11 Mar 2003 11:32:15 +0100 Original-To: Rob Browning In-Reply-To: <87adg2kbdn.fsf@raven.i.defaultvalue.org> (Rob Browning's message of "Mon, 10 Mar 2003 18:14:28 -0600") User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 Original-cc: guile-devel@gnu.org 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:2063 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2063 Rob Browning writes: > Mikael Djurfeldt 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 ) (y )) > arguments. > > Then say someone writes module (bar) that defines do-fancy-+ for ((x > ) (y )) 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