Re: CLOS-style MOP for Guile ?

[mike@olan.com (Michael N. Livshin)]

Bernard URBAN <Bernard.Urban@meteo.fr> writes:

> I have currently a much cleaner stklos
> port, which uses modules more consistently, and with
> a mixture of hobbit compiled code and unexeced code.
> Unexeced code gives a fast start-up and tiny initialization time, and
> compiled code contributes to good speed after that.
> I will probably release it in a few days.

Cool!

>     Christian> The `define-generic' macro expands into a
>     Christian> `define-public' rather than just a `define'.
> 
>     Christian> I do not know enough about the module system to say
>     Christian> what the precise implication of this is, but it most
>     Christian> likely do not implement the full module awareness as
>     Christian> you define it.
> 
> Absolutely true. I do not know if the wished behaviour is so
> important in practice, as it may be sufficient to have the module system control
> the classes. If a generic has methods for class_A and class_B,
> respectively defined (publicly) in modules A and B, if module B is not in use,
> you have no way (until cheating heavily with generic-methods and 
> method-specializers) to give an instance of class_B to the generic.

Err... Actually, the problem is not that.

Consider this situation:

Module A defines public class class-A, and specializes generic some-generic
for A.  The generic is being called in some of A's functions, but users of
the module A have know way of knowing this implementation detail.

Now, module B imports A, derives class-B from A and specializes some-generic
for B.  Then, A's functions that use some-generic will behave differently
when handed an object of class class-B, breaking in many creative ways.

Note, I'm *not* claiming that such a situation is very likely to occur in
practice, but, at least theoretically, it can.

HTDtSYVM [1],
mike.

[1] - Hope That Didn't Scare You Very Much :)