From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Pirotte Newsgroups: gmane.lisp.guile.devel Subject: Re: goops - accessors, methods and generics Date: Fri, 22 Feb 2013 20:11:10 -0300 Message-ID: <20130222201110.0a9e715c@capac> References: <20130221195139.59f41d13@capac> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1361574721 21712 80.91.229.3 (22 Feb 2013 23:12:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2013 23:12:01 +0000 (UTC) Cc: guile-devel@gnu.org To: Daniel Hartwig Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 23 00:12:24 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U91mu-0004up-7J for guile-devel@m.gmane.org; Sat, 23 Feb 2013 00:12:20 +0100 Original-Received: from localhost ([::1]:55179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U91mZ-0002Na-B1 for guile-devel@m.gmane.org; Fri, 22 Feb 2013 18:11:59 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:54737) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U91mT-0002NV-Ac for guile-devel@gnu.org; Fri, 22 Feb 2013 18:11:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U91mN-00005L-DD for guile-devel@gnu.org; Fri, 22 Feb 2013 18:11:53 -0500 Original-Received: from maximusconfessor.all2all.org ([62.58.108.13]:50225) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U91mN-0008Lp-7U for guile-devel@gnu.org; Fri, 22 Feb 2013 18:11:47 -0500 Original-Received: from localhost (unknown [192.168.0.2]) by maximusconfessor.all2all.org (Postfix) with ESMTP id 53526A04C110; Sat, 23 Feb 2013 00:11:20 +0100 (CET) Original-Received: from maximusconfessor.all2all.org ([192.168.0.1]) by localhost (maximusconfessor.all2all.org [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id B60YrLsVzJSz; Fri, 22 Feb 2013 23:40:40 +0100 (CET) Original-Received: from capac (unknown [139.82.89.157]) by maximusconfessor.all2all.org (Postfix) with ESMTPSA id DDC08A04C0F4; Sat, 23 Feb 2013 00:11:12 +0100 (CET) In-Reply-To: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 62.58.108.13 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15805 Archived-At: Hi Daniel, thanks for your answer, but where i understand a strict name space will lea= d to merging the generic(s) from/with the ones that comes from the modules you a= re importing [as opposed to a general 'goops' name space], i disagree that thi= s would be a 'pre limitation' that provides a proper handling of the problem we are ta= lking about. > Note that is a superclass of , so these are > already generic functions.=20 great, so the interface is defined, right? > Consider these situations followed by introducing any of your example > class definitions: > - module A binds =E2=80=98define=E2=80=99 to a non-procedure; or > - modules B and C bind =E2=80=98define=E2=80=99 to different procedures. let's stick to goops, shall we > In your example the two classes share a common interface, but this > interface is never defined anywhere. you just said above that it is, at least for accessors: i am also defending= the idea that it should always automatically create a generic function [for methods = as well] if none exists. > So if I have code that wants to work with any widget, which module shoul= d be > imported to get the canonical interface definition? the canonical definition comes from the first imported module that [also] d= efines the generic: this is what occurs in the mg-3.scm example, and that actually= works fine, as you know. however in the mg-4 example, it does not, which i think is an implementation problem: since i am asking guile to merge... it should import mg-1 and merg= e its own generics with the imported ones. there is no reason, and certainly not the = name space conservativness, why this is not properly implemented in guile. > If the interface is the same, you have a candidate for superclass. yes, that is a possibility, and in some cases i agree that it is the way to= go, but it should not be imposed on the user. Cheers, David