On Sun, Aug 3, 2014 at 3:50 AM, Hans Hübner <hans.huebner@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".