Hey! Andy Wingo <wi...@pobox.com> writes:
> Here's the problem, for me: > > scheme@(guile-user)> (define-record-type <foo> (make-foo x) foo? (x > foo-x)) > scheme@(guile-user)> (make-foo 10) > $1 = #<<foo> x: 10> > scheme@(guile-user)> (struct-vtable $1) > $2 = #<vtable:2356fa0 pruhsruhpwphuhuh 6a55640> > scheme@(guile-user)> (struct-vtable $2) > $3 = #<vtable:2356fa0 pruhsruhpwphuhuh 2356fa0> > scheme@(guile-user)> (struct-vtable $3) > $4 = #<vtable:2356fa0 pruhsruhpwphuhuh 2356fa0> > > 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 = #<<class> <> 368e870> > scheme@(guile-user)> (class-of $3) > $6 = #<<class> <> 368e870> Yes, understood. >>> So we need a <basic-class>, interposed between <class> and <object>, >>> which will be the real root of our class meta-object hierarchy. >> >> Why? >> >> Couldn’t ‘scm_i_define_class_for_vtable’ build a full-blown class, >> populating its CPL, its ‘slots’ 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 ‘scm_i_define_class_for_vtable’ altogether, and instead have vtables directly behave as classes, right? > Vtables *are* classes, on a fundamental level. Bare vtables are not as > nice as <class>, 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 à la SRFI-9 can be implemented. GOOPS objects are currently heavyweight compared to raw structs. Thanks, Ludo’.
