<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 1, 2014 at 9:48 PM, Steve Haflich <span dir="ltr"><<a href="mailto:shaflich@gmail.com" target="_blank">shaflich@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I'm typing on a phone in a dog park. Expect brevity and typos.</p>
<p dir="ltr">Why do think one or another behavior is incorrect? slot-value is required only to return the correct value (etc.) if all the metaobjects are of classes "specified" in the standard. The MOP prohibits you from changing or extending MOP gfs when all the discriminating args are of specified classes. If you use customized class or slot-definition metaclasses then slot-value needs to obey some or all of the full slot-value-using-class protocol, but otherwise your code cannot legally change what s-v does or returns.</p>


<p dir="ltr">This is spelled out somewhere in the MOP in a section on restrictions on user code or something like that.<br></p></blockquote><div>I think I found the subsection you refer to: AMOP  5.3.1 (pp. 142-144) "Implementation and User Specialization", which contains two sub-subsections with titles starting with "Restrictions on".<br>
</div><div>I will try to decipher those and their implications now that I have renewed motivation to do so.<br><br></div><div>Thank you very much Steve, you're always so helpful in these matters.<br><br></div></div></div>
</div>