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 shaflich@gmail.com 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 swmckay@gmail.com 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 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 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
pro mailing list pro@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro