<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">1. intern-eql-specializer is not strictly necessary. eql-specializer metaobjects are actually not strictly necessary. Case in point: LispWorks doesn’t have eql-specializer metaobjects in its MOP implementation at all. In LispWorks, eql specializers are just lists of the form `(eql ,object). I don’t have the impression that this has a negative impact on performance, or so. When eql specializers are just lists like this, then I believe the whole issue of getting rid of ‘garbage’ eql specializers is a non issue: Once a method with a particular eql specializer is removed, the corresponding object can be freed (unless other references exist, of course). (You still have the issue of not easily being able to get rid of ‘garbage’ classes.)</div><div class=""><br class=""></div><div class="">2. Don’t take the CLOS MOP specification as some kind of final word on how CLOS should be implemented. The CLOS MOP was still work in progress when the specification was published, and this is acknowledged in “The Art of the Metaobject Protocol.” It’s perfectly possible that there are better ways to implement CLOS with better protocols. In practice, almost actual CLOS implementations actually deviate in one way or another from the CLOS MOP specification, which is partially for historical reasons, partially because there are holes in the CLOS MOP specification, partially because parts of the spec are not implementable, and partially because certain aspects can actually be implemented better.</div><div class=""><br class=""></div><div class="">3. I’m not convinced that eql specializers are the most pressing concern. For example, the total lack of a good specification for method combination metaobjects is much more worrisome. Also, the generic function invocation protocol is too restrictive, in that it doesn’t allow for more modern inlining techniques (like polymorphic inline caches, or trace-based JIT compilation, for example). There is probably more.</div><div class=""><br class=""></div><div class="">4. If you are really concerned about eql specializers using up too much memory (and I’m really wondering what kind of use case that might be), then it’s probably better to roll your own approach to make that work. You don’t even need to go through the MOP, just implement your own dispatch mechanism, maybe even completely independent from CLOS. It’s not that hard, and you can come up with rules for your own dispatch mechanism that don’t have to be in line with what CLOS or the CLOS MOP require at all.</div><div class=""><br class=""></div><div class="">Pascal</div><div class=""><br class=""></div><div class=""><div class=""></div></div><div class="">
<div class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">--</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">Pascal Costanza</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">The views expressed in this email are my own, and not those of my employer.</span></div><div class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class=""><br class=""></span></div><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>