On Fri, Dec 26, 2014 at 11:38 AM, Kenneth Tilton <k...@tiltontec.com> wrote: > Why is there no way to remove an interned EQL specializer meta-object?
Because no way to do this was defined in the MOP. It's unclear whether you suggest there should be some programmatic way to unintern an EQL specializer, or whether the system should do it automatically. But neither makes a lot of sense. If a user call uninterned an EQL specializer while there were still methods specialized upon it, then the MOP would become inconsistent. > They get defined in the context of a method definition, They are also interned by an explicit user-code call to INTERN-EQL-SPECIALIZER, which would be a reasonably thing to do it using the MOP directly to install new methods, or even to test whether any method or gf exists specialized on that EQL object. > 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. (defparameter .kenny. (intern-eql-specializer 'tilton)) How would the MOP do reference counting on this metaobject. If the implementation spontaneously uninterned it, then a subsequent call to i-e-s would return a different metaobject, in violation of the MOP specification. > 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. Yes, indeed. I expect this thread is a lot of owrrying about nothing important. But as I suggested previously, an implementation with weak hash tables could unintern EQL specializers safely if it wanted to bother. _______________________________________________ pro mailing list pro@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
