[pro] [MOP] Does intern-eql-specializer serve any real purpose?

[Steve Haflich]

On Fri, Dec 26, 2014 at 11:38 AM, Kenneth Tilton <ken at 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.