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 <k...@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.beaud...@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 > http://tiltontec.com > "In a class by itself." *-Macworld* > > > > _______________________________________________ > pro mailing list > pro@common-lisp.net > http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro > >
_______________________________________________ pro mailing list pro@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro