<div dir="ltr">The specializers are probably interned for the sake of allowing<div>better optimization of EQL dispatch. I don't think it'll grow without</div><div>bounds; it probably gets big enough to hold all of the methods with</div><div>EQL dispatch, and then grows no further.</div><div><br></div><div>Honestly, I don't use EQL methods much myself, if they can be</div><div>avoided by using SELECT.</div><div><br></div><div>--S</div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 26, 2014 at 10:33 AM, Kenneth Tilton <span dir="ltr"><<a href="mailto:ken@tiltontec.com" target="_blank">ken@tiltontec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Not sure where I see either "forever growing" or "memory leak". Come to think of it, not sure what you mean by "mandatory". It is a spec of how the MOP should work internally. Do you have some other way in mind for things to work?<div><br></div><div>I mean, it sounds like you might be talking about forever adding and removing eql-specialized methods, but I'd rather not guess. Even if so, nothing stops the implementation from GCing unused specializer metaobjects.</div><div><br></div><div>-hk</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 26, 2014 at 2:10 AM, Jean-Claude Beaudoin <span dir="ltr"><<a href="mailto:jean.claude.beaudoin@gmail.com" target="_blank">jean.claude.beaudoin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hello CL Pros,<br><br></div>Lately I have been improving the MOPishness of MKCL and that brought me in contact with the specification of intern-eql-specializer in AMOP.<br><br></div>The EQ requirement on its returned value seem to me to dictate a hash-table implementation (PCL and its derivatives all seem to do just that).<br><br></div>The problem I see with this is that it will be a "for ever growing" hash-table with not upper bound in sight. And the "purpose" of such a mandatory built-in memory leak also completely escapes me. Could any of you share some insight on this question, please?<br><br></div>Thank you,<br><br></div>JCB<br><br></div>
<br>_______________________________________________<br>
pro mailing list<br>
<a href="mailto:pro@common-lisp.net" target="_blank">pro@common-lisp.net</a><br>
<a href="http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Kenneth Tilton<div>Fort Lauderdale, FL</div><div><a href="http://tiltontec.com" target="_blank">http://tiltontec.com</a><br></div><div>"In a class by itself." <i>-Macworld</i></div><div><br></div><div><br></div></div></div>
</font></span></div>
<br>_______________________________________________<br>
pro mailing list<br>
<a href="mailto:pro@common-lisp.net">pro@common-lisp.net</a><br>
<a href="http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro" target="_blank">http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro</a><br>
<br></blockquote></div><br></div></div></div>