From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.devel Subject: Re: goops - accessors, methods and generics Date: Fri, 22 Feb 2013 09:16:54 +0800 Message-ID: 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 1361496201 5671 80.91.229.3 (22 Feb 2013 01:23:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2013 01:23:21 +0000 (UTC) Cc: guile-devel@gnu.org To: David Pirotte Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Feb 22 02:23:44 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 1U8hMV-0000t5-KX for guile-devel@m.gmane.org; Fri, 22 Feb 2013 02:23:43 +0100 Original-Received: from localhost ([::1]:40418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8hMA-0003jN-HW for guile-devel@m.gmane.org; Thu, 21 Feb 2013 20:23:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:51877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8hM7-0003jH-Pm for guile-devel@gnu.org; Thu, 21 Feb 2013 20:23:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8hM3-0004FJ-IG for guile-devel@gnu.org; Thu, 21 Feb 2013 20:23:19 -0500 Original-Received: from mail-ie0-x236.google.com ([2607:f8b0:4001:c03::236]:57234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8hM3-0004F7-De for guile-devel@gnu.org; Thu, 21 Feb 2013 20:23:15 -0500 Original-Received: by mail-ie0-f182.google.com with SMTP id k14so171274iea.27 for ; Thu, 21 Feb 2013 17:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=BzHjylVY5uAhWD4Us1Ydz6dI4MPYTjdrCDajGmCPREk=; b=PU2y9U4S+ErvJYFdxSYn7lNwPNmtQ1ZWw7k7KjWI5XH6tciJDZTsnpofQqfgvXRiue ziGlIk69FxcM9JJmdLe/PJTnq1KSqbvWLPeFt/hD6ZWPaxg07JmrJYyEWRKL/NInlDTi QF3cv6nDy9LLsGNAXwjMl3T/SSKeKratmLFr5z+ZFgC8Wgbdwd5uiOZvQP2A3hR7JNGE 7GtC35nY/WKeP4J6MiM2SaLcLq+2Pr43hdEHxyOXizUuVHkZrv6Ho5LhJqmTwmBLsKgP 2mr4g8bR1fSP9aLnucSkaKij94wt1SwIWuTT2BAu5PsxWcJ0uvsdSpO0rKZXA6M9u7yI vJNg== X-Received: by 10.50.40.131 with SMTP id x3mr14179749igk.10.1361495815102; Thu, 21 Feb 2013 17:16:55 -0800 (PST) Original-Received: by 10.64.76.51 with HTTP; Thu, 21 Feb 2013 17:16:54 -0800 (PST) In-Reply-To: <20130221195139.59f41d13@capac> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c03::236 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:15795 Archived-At: Hi It seems you are expecting some CLOS behaviour in a language that can not support it. The accessors are generic functions, but each of your modules creates a unique generic function, there is no implicit namespace sharing in Scheme. Define a base module with an appropriate superclass or interface definition (generics); Scheme requires it. On 22 February 2013 06:51, David Pirotte wrote: > Hello all, > > given the following 4 modules, I am facing what I consider an > inconsistent goops behavior and have one problem which leads to my > recurrent request of goops default behavior should be to > [a] always > create a generic function for accessors and methods that do not [yet] > have one, *visible in the entire guile space [all modules]* Note that is a superclass of , so these are already generic functions. There is no global binding escalation in Scheme. 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. Your suggestion is appropriate in a language like Common Lisp with dynamic scoping, and separate namespaces for function and non-function bindings. Not so appropriate for Scheme. In your example the two classes share a common interface, but this interface is never defined anywhere. So if I have code that wants to work with any widget, which module should be imported to get the canonical interface definition? Indeed, it will either have to be created using a common superclass or manually defined generics (as you later observe). These widget implementations will then have to import the base module to explicitly share in the interface. > and [b] the > default behavior should be '(merge-generics replace warn-override-core > warn last) [but that at least that one I can set using :duplicate, I know= ] The default behaviour is conservative with regards to namespace separation. If you desire this behaviour it seems best to explicitly ask for it. With CLOS a different default can be expected to apply because bindings in the underlying language already work in a similar way. > what is more of a problem with the existing goops default, for me, is > expressed in the mg-4.scm 'case': i can not make it work unless I > manually create another module, manually making generics and make sure > it is loaded before ... In a language like Scheme this can not be avoided. Namespaces must be managed quite explicitly. In your example, mg-1 and mg-2 are not sharing any bindings. It is not appropriate to assume that =E2=80=98dialog=E2=80=99 in either is relate= d to the other. If they implement a common interface, as seems obvious in the example, then they need to import the generic bindings for that from a common base module. Such a module should either define a superclass or you can manually define the generics. > or rename the accessors, which both solutions > are really against my expectation and [long] CLOS practice: why should > I have to manually do things which are inherent to oop [same name for > slots pertaining to different classes is so common that i can not see > any large application not having to do so, for semantic reasons]. GOOPS can not do everything the same as CLOS due to fundamental differences between the underlying languages. If the interface is the same, you have a candidate for superclass. Either way, any code that hopes to use the (generic) interface needs to import the bindings from somewhere, and that will be a module containing either a superclass or a set of manually defined generics. Regards