Re: goops proposal: proper struct classes

[Ludovic Courtès]

Hey!

Andy Wingo <address@hidden> 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’.