heads up: goops class export

heads up: goops class export

[Andy Wingo]

Hello again,

Currently when you define a SMOB type or set a name on a vtable, a
corresponding class is automatically exported from (oop goops).  This
breaks modularity, and I think we should stop doing it in 2.2.

I will make this change at some point, if there are no objections.

Andy
-- 
http://wingolog.org/

Re: heads up: goops class export

[Ludovic Courtès]

Hi!

Andy Wingo <wingo@pobox.com> writes:

> Currently when you define a SMOB type or set a name on a vtable, a
> corresponding class is automatically exported from (oop goops).  This
> breaks modularity, and I think we should stop doing it in 2.2.

I agree that they should not be exported from (oop goops).

However, how should GOOPS users access these classes then?  There needs
to be a way to get the class object associated with a SMOB type, for
instance.

Thanks,
Ludo’.

Re: heads up: goops class export

[Andy Wingo]

Hi!

On Tue 03 May 2011 10:50, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> Currently when you define a SMOB type or set a name on a vtable, a
>> corresponding class is automatically exported from (oop goops).  This
>> breaks modularity, and I think we should stop doing it in 2.2.
>
> I agree that they should not be exported from (oop goops).
>
> However, how should GOOPS users access these classes then?  There needs
> to be a way to get the class object associated with a SMOB type, for
> instance.

Hum, a good question!  Perhaps smob-name->class, as there is
gtype->class; and of course there is class-of.

Andy
-- 
http://wingolog.org/

Re: heads up: goops class export

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> writes:

> On Tue 03 May 2011 10:50, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> writes:
>>
>>> Currently when you define a SMOB type or set a name on a vtable, a
>>> corresponding class is automatically exported from (oop goops).  This
>>> breaks modularity, and I think we should stop doing it in 2.2.
>>
>> I agree that they should not be exported from (oop goops).
>>
>> However, how should GOOPS users access these classes then?  There needs
>> to be a way to get the class object associated with a SMOB type, for
>> instance.
>
> Hum, a good question!  Perhaps smob-name->class,

Yes, why not.  (It’s equivalent to (@@ (oop goops) foobar) in terms of
providing access to everyone, though.)

Thanks,
Ludo’.

Re: heads up: goops class export

[Andy Wingo]

Hi :)

On Tue 03 May 2011 14:19, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> smob-name->class
>
> Yes, why not.  (It’s equivalent to (@@ (oop goops) foobar) in terms of
> providing access to everyone, though.)

OK.  GOOPS really isn't for the ocap folks, given
class-direct-subclasses, the cross-module implications of defining a new
method on a generic, etc :)

Andy
-- 
http://wingolog.org/

Re: heads up: goops class export

[Andy Wingo]

Hi,

On Sun 01 May 2011 22:32, Andy Wingo <wingo@pobox.com> writes:

> Currently when you define a SMOB type or set a name on a vtable, a
> corresponding class is automatically exported from (oop goops).  This
> breaks modularity, and I think we should stop doing it in 2.2.
>
> I will make this change at some point, if there are no objections.

I have made this change in guile-master.  You can get at the class of a
record type by grubbing around in (class-direct-subclasses <top>), but
the real solution will be to make record type descriptors instances of
<basic-class>.  That will come lter.

Andy
-- 
http://wingolog.org/