From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Grover Newsgroups: gmane.lisp.guile.user Subject: Generic-methods from multiple modules should merge Date: Tue, 10 Jan 2006 14:36:19 -0500 Message-ID: <43C40CB3.5070702@mail.msen.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1136921694 20018 80.91.229.2 (10 Jan 2006 19:34:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2006 19:34:54 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Jan 10 20:34:48 2006 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EwPGR-0004X1-Ru for guile-user@m.gmane.org; Tue, 10 Jan 2006 20:34:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EwPIR-0007Lb-HB for guile-user@m.gmane.org; Tue, 10 Jan 2006 14:36:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EwPIM-0007Jb-LP for guile-user@gnu.org; Tue, 10 Jan 2006 14:36:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EwPIK-0007FE-0O for guile-user@gnu.org; Tue, 10 Jan 2006 14:36:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EwPIJ-0007Ex-SC for guile-user@gnu.org; Tue, 10 Jan 2006 14:36:35 -0500 Original-Received: from [148.59.80.48] (helo=ww8.msen.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EwPKp-0005zm-10 for guile-user@gnu.org; Tue, 10 Jan 2006 14:39:11 -0500 X-Sent-To: Original-Received: from [192.168.1.221] (pool-151-196-6-194.balt.east.verizon.net [151.196.6.194]) (authenticated bits=0) by ww8.msen.com (8.13.4/8.13.4) with ESMTP id k0AJYSp0069309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 Jan 2006 14:34:29 -0500 (EST) (envelope-from awgrover@mail.msen.com) User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en Original-To: guile-user@gnu.org Received-SPF: Pass (sender authenticated); receiver=(null); client-ip=151.196.6.194; envelope-from= Received-SPF: Pass (sender authenticated); receiver=(null); client-ip=151.196.6.194; helo=[192.168.1.221] X-Milter: Spamilter (Reciever: ww8.msen.com; Sender-ip: 151.196.6.194; Sender-helo: [192.168.1.221]; ) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:5074 Archived-At: I have 2 goops classes, each in their own module, which happen to have a slot called 'request (with an accessor). Unfortunately, "use-modules" ends up importing the generic-method from only one of the modules (the last, lexically). Thus, I can't call (request first-class). Thus: (use-modules (awg first-class)) (use-modules (awg second-class)) ... (request some-object-of-first-class) => No applicable method .... [on first-class] ; and, if you introspected on the generic-method 'request, ; you'd only see one method/procedure. This seems documented in the manual under "Module System Quirks:" When two or more used modules export bindings with the same names, the last accessed module wins. If the generic-method/accessor were part of a logical interface, then a super-class could declare it, and my 2 (sub-) classes would add their methods to the generic-method, and everything would be fine. However, the two classes don't share an interface, they just happen to have the same slot-name (admittedly with the same object in it). It doesn't strike me as right to use a super-class such as "request-accessor-class" with just that slot/accessor. Imagine doing this for each case: 'color, 'phone-number, 'etc. And renaming seems wrong, not to mention tedious. I'd have to remember which class's accessor had been renamed (or not). I think the right thing is to have the module system "merge" the generic methods. Thus, when importing a module, if the module's symbol is bound to a generic-method, and if the symbol is already bound to a generic-method (in the "using" module), add the methods to the existing generic-method. Then, all of the methods are visible under the generic name. Actually, instead of merging into the existing generic-method, a new generic-method should be created in the "using" module, and the two "used" ones merged in to that. I believe this preserves the expectations of lexical scope better. On the other hand, I believe a similar existing situation behaves differently: Importing a generic-function, and then "adding" a method to it does modify the generic-function as seen by the "used" module. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user