From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: goops proposal: proper struct classes Date: Thu, 05 May 2011 22:19:16 +0200 Message-ID: <8739ksnbnf.fsf@gnu.org> References: <87fwot14wl.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1304626766 30330 80.91.229.12 (5 May 2011 20:19:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 May 2011 20:19:26 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu May 05 22:19:22 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QI518-0007Qo-GT for guile-devel@m.gmane.org; Thu, 05 May 2011 22:19:22 +0200 Original-Received: from localhost ([::1]:51264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI518-0003iq-0W for guile-devel@m.gmane.org; Thu, 05 May 2011 16:19:22 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:40590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI515-0003ia-R3 for guile-devel@gnu.org; Thu, 05 May 2011 16:19:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QI514-0006wC-MR for guile-devel@gnu.org; Thu, 05 May 2011 16:19:19 -0400 Original-Received: from solo.fdn.fr ([80.67.169.19]:50336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QI514-0006w8-GX for guile-devel@gnu.org; Thu, 05 May 2011 16:19:18 -0400 Original-Received: from nixey (reverse-83.fdn.fr [80.67.176.83]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: lcourtes) by smtp.fdn.fr (Postfix) with ESMTPSA id 3E9594420A; Thu, 5 May 2011 22:19:17 +0200 (CEST) X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 16 =?iso-8859-1?Q?Flor=E9al?= an 219 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu In-Reply-To: (Andy Wingo's message of "Thu, 05 May 2011 20:25:20 +0200") User-Agent: Gnus/5.110017 (No Gnus v0.17) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 80.67.169.19 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:12437 Archived-At: Hey! Andy Wingo writes: > Here's the problem, for me:=20 > > scheme@(guile-user)> (define-record-type (make-foo x) foo? (x f= oo-x)) > scheme@(guile-user)> (make-foo 10) > $1 =3D #< x: 10> > scheme@(guile-user)> (struct-vtable $1) > $2 =3D # > scheme@(guile-user)> (struct-vtable $2) > $3 =3D # > scheme@(guile-user)> (struct-vtable $3) > $4 =3D # > > See? The struct's vtable is actually an instance of another vtable -- > of another class -- and that metaclass is a vtable-vtable (because $3 > and $4 are equal). > > So class-of $2 should yield the class-of $3, which is actually some > other bug: > > scheme@(guile-user)> (class-of $2) > $5 =3D #< <> 368e870> > scheme@(guile-user)> (class-of $3) > $6 =3D #< <> 368e870> Yes, understood. >>> So we need a , interposed between and , >>> which will be the real root of our class meta-object hierarchy. >> >> Why? >> >> Couldn=E2=80=99t =E2=80=98scm_i_define_class_for_vtable=E2=80=99 build a= full-blown class, >> populating its CPL, its =E2=80=98slots=E2=80=99 slot, etc.? > > Yes, it could. I didn't mention that. I think that such a duplicate > hierarchy is unnecessary, because we can define methods for some of the > class protocol (class-name at least!). So that would mean getting rid of =E2=80=98scm_i_define_class_for_vtable=E2= =80=99 altogether, and instead have vtables directly behave as classes, right? > Vtables *are* classes, on a fundamental level. Bare vtables are not as > nice as , but they do describe instances. SCM_CLASS_OF() is > SCM_STRUCT_VTABLE(). OK, it would be more elegant. Can it be achieved without GOOPsifying too much the rest of Guile? I mean, creating and accessing raw structs should remain as lightweight as currently, so that syntactic-only records =C3=A0 la SRFI-9 can be implemented. GOOPS objects are currently heavyweight compared to raw structs. Thanks, Ludo=E2=80=99.