The specializers are probably interned for the sake of allowing
better optimization of EQL dispatch. I don't think it'll grow without
bounds; it probably gets big enough to hold all of the methods with
EQL dispatch, and then grows no further.

Honestly, I don't use EQL methods much myself, if they can be
avoided by using SELECT.

--S


On Fri, Dec 26, 2014 at 10:33 AM, Kenneth Tilton <ken@tiltontec.com> wrote:
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?

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.

-hk


On Fri, Dec 26, 2014 at 2:10 AM, Jean-Claude Beaudoin <jean.claude.beaudoin@gmail.com> wrote:
Hello CL Pros,

Lately I have been improving the MOPishness of MKCL and that brought me in contact with the specification of intern-eql-specializer in AMOP.

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).

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?

Thank you,

JCB


_______________________________________________
pro mailing list
pro@common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro




--
Kenneth Tilton
Fort Lauderdale, FL
"In a class by itself." -Macworld



_______________________________________________
pro mailing list
pro@common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro