[pro] AMOP question: When and where is slot-value-using-class called?

[Jean-Claude Beaudoin]

On Sun, Aug 3, 2014 at 3:50 AM, Hans Hübner <hans.huebner at gmail.com> wrote:

> Jean-Claude,
>
> the basic point that the other, more knowledgeable responders made, was:
>  You cannot define a method on slot-value-using-class specializing on
> standard-class and expect the same behavior across implementations.  This
> is because standard-class may be used within the lisp implementation itself
> and/or be treated by the compiler differently to achieve better
> performance.  If you want to use slot-value-using-class, you need to define
> your own metaclass and specialize the methods on that.
>

I think Hans that you are expressing here what is probably the most
commonly held opinion as to the current state of the practice in that area.
Which is a valuable data point in itself since it would represent the "de
facto" situation in this matter.  But I wanted to go further than that.
What I really wanted was to find out for myself where the exact demarcation
line was by the book, if there was any.

And Steve pointed right at it here
<http://franz.com/support/documentation/current/doc/mop/concepts.html#portable>.
It turns out that the line "by the book" is not where the "commonly held
opinion" would have it.  It is quite a bit further.  It is even further
than most implementation would be ready to tolerate since the text opens up
a space between allocate-instance and the object "initialization" where
things could be done methodwise. This is slicing the salami pretty thin
here, so thin that it may start to be translucent. I wouldn't dare try to
explore that area since my reading of the source code of a few
implementations make me believe the behaviors would be all over the place
in there.

Thanks to this I have now a much better understanding of the design space
extent for optimization of CLOS slot accessors, both "de jure" and "de
facto".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140803/ebd146cb/attachment.html>