From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a subclass Date: Sat, 07 Feb 2015 16:37:49 +0100 Message-ID: <87oap57mwi.fsf@pobox.com> References: <20141219174633.6efb845e@capac> <8761btfcni.fsf@pobox.com> <20150126230044.2d1e71de@capac> <87sieweie4.fsf@pobox.com> <20150127171115.6172ccea@capac> <87zj94c5rv.fsf@pobox.com> <20150130115015.5c8e3192@capac> <878ugb9nbk.fsf@pobox.com> <20150206150933.09e166f6@capac> <87a90r7wwr.fsf@pobox.com> <20150206220637.310db45e@capac> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423323484 13651 80.91.229.3 (7 Feb 2015 15:38:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Feb 2015 15:38:04 +0000 (UTC) Cc: guile-devel To: David Pirotte Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 07 16:38:04 2015 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 1YK7SM-0001AG-0z for guile-devel@m.gmane.org; Sat, 07 Feb 2015 16:38:02 +0100 Original-Received: from localhost ([::1]:53516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK7SL-00052S-HZ for guile-devel@m.gmane.org; Sat, 07 Feb 2015 10:38:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK7SI-00052N-7P for guile-devel@gnu.org; Sat, 07 Feb 2015 10:37:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YK7SD-0000Pz-Ns for guile-devel@gnu.org; Sat, 07 Feb 2015 10:37:58 -0500 Original-Received: from pb-sasl1.int.icgroup.com ([208.72.237.25]:51990 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK7SD-0000Ow-IP for guile-devel@gnu.org; Sat, 07 Feb 2015 10:37:53 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id A6E4B31BA8; Sat, 7 Feb 2015 10:37:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=LOG0UcBatqO+EsoI+cB5cMua7Tc=; b=h+F4mP uzO8qGCJfrVQWGcLGfudN7b1wtoB5QnaNXLUb5pfsCHBLSBl31AealEyNq3xkCs7 YnsXfB4YDbldtlY7KKwS2zCFhrZegljhznZagc6MHHw9u84iWg0z+LZdzUGKgLlF 87IpFQ+7EFbyP4y+eEP2mI+XtKzVuetJKh02g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=KzMPRcDFeZMNTtxHidMBrPxA8BezmraJ BSA/v7515kiWNHofp3C5FyyLh2sK3wpOF9VnKYtHfwnRImS0Jf3ib2R/foCfjERN kwkR1Fy0aolbBz46L86YCfIHi1+J1Vd8GUcj6pzx4hR7SJRS3Vp7ygx129MFB0jr XFFfR1TWYSU= Original-Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 9E14F31BA7; Sat, 7 Feb 2015 10:37:52 -0500 (EST) Original-Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 0483631BA6; Sat, 7 Feb 2015 10:37:51 -0500 (EST) In-Reply-To: <20150206220637.310db45e@capac> (David Pirotte's message of "Fri, 6 Feb 2015 22:06:37 -0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-Pobox-Relay-ID: 4718435C-AEDF-11E4-8F34-B05EFC961345-02397024!pb-sasl1.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.72.237.25 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:17654 Archived-At: Hello again :) On Sat 07 Feb 2015 01:06, David Pirotte writes: >> So, we should be precise with terminology :) In GOOPS, subclasses do >> not inherit accessor methods. (There was a bug in which they would; I >> fixed that.) Each subclass gets its own accessor method defined, if and >> only if it has the corresponding slot, and that method is not inherited. > > Here we don't agree, and to me, this is a bug, not a feature :) Unfortunately if the question is about GOOPS's design, I am certain that the current stable-2.0 and master behavior follows the design, simply because it does the same thing as Guile 1.8, before I picked up GOOPS maintenance and started introducing bugs :) So let us not argue over that. Let us instead treat your concern as request that the behavior should be different. > we should follow the clos spec here Hmm, I agree in general, but you have to understand that the CLOS spec is not identical to TinyCLOS, the predecessory of stklos. They are similar but not the same. Because of this, diverging from CLOS is not a bug. That said I think the CLOS way is usually better, but we are limited by two things: compatibility with past behavior (not a terrible concern in this instance, given the lack of outcry when I broke things), and secondly by hack-power. In particular I do not have any additional free time to spend on GOOPS features in the near future. This feature you are asking for requires: * more logic in method-applicable? for accessor methods that would 1. check the list of effective slot definitions in the target object 2. for each slot, get the direct slot definition - currently there is no long from effective to direct, we'd have to add that 3. if the target object has a slot with the same direct slot definition as the one associated with the accessor method, then the method applies, otherwise not * compile-time specialization for methods, as in 583a23bf104c84d9617222856e188f3f3af4934d which was later reverted Open questions would be, do we expose method-applicable? as a generic, there's some gnarly circularity because these methods are part of the method dispatch protocol, do we expose more of the slot protocol to users (it's currently somewhat opaque and unfinished), how to document all of this, we need a bunch of tests too, how do you relate effective slots to direct slots in the CLOS case where you can make composite slots, etc. It's a bit of work and I need to do other things :) Andy -- http://wingolog.org/