Why is there no way to remove an interned EQL specializer meta-object? They get defined in the context of a method definition, so one just needs to do some good old-fashioned engineering: method-specializer reference tracking leveraged at method removal time to know when to toss the hash table entry.
I am more interested in why this is perceived as a problem, but if the OP is doing some dynamic metaprogramming I can imagine a use case. On Fri, Dec 26, 2014 at 11:58 AM, Steve Haflich <[email protected]> wrote: > Scott (long time no see): > > This reply doesn't seem correct at all. Interning an EQL specializer > does not directly have anything to do with methods (although it is > most often performed by the implementation when an EQL method is > defined) nor would methods be remembered in the hash table or > whatever the implementation uses to intern them. > > An EQL specializer must exist in order for METHOD-SPECIALIZERS to have > something to return, and as an argument to be passed to functions like > SPECIALIZER-DIRECT-GENERIC-FUNCTIONS > SPECIALIZER-DIRECT-METHODS > EQL-SPECIALIZER-OBJECT > > Specializers are also necessary if one wants to manipulate generic > functions and methods directly using the MOP instead of with the > DEFGENERIC and DEFMETHOD macros. If for no other reason, specializers > exist because the MOP must be self-reflexive. > > True, there is no way to remove an interned EQL specializer, which may > be an oversight in the MOP. But there will be exactly one entry for > each unique specializer in the EQL hash table or whatever else is used > for their internment. I suppose an implementation that features weak > hashtables could use one for EQL specializers, since if there were no > other references to one there would be no portable way to ask if it > was still there. > > "Growing without bounds" is no different than what happens when a new > symbol is interned, or a new function or method is defined on an > interned symbol. Rarely any problem in typical programming. > > On Fri, Dec 26, 2014 at 7:38 AM, Scott McKay <[email protected]> wrote: > > 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 <[email protected]> > 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 > >> <[email protected]> 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 > >>> [email protected] > >>> 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 > >> [email protected] > >> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro > >> > > > > > > _______________________________________________ > > pro mailing list > > [email protected] > > http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro > > > > _______________________________________________ > pro mailing list > [email protected] > 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 [email protected] http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
