On Fri, Dec 26, 2014 at 10:10 PM, Steve Haflich <shaflich@gmail.com> wrote:

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

Wait. Are we in the religious zone now? This is engineering.

It's unclear
whether you suggest there should be some programmatic way to unintern
an EQL specializer,

Yeah, it is trivial if you want to make it work. No help of course for the religious zone.

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.

What is the user up to, inside the MOP? Why are they doing something so perverse? Whatever reason they have, they are inside the mop they are authoring. (Guessing internal-eql-specializer is not exported). If their mop worries about IES leaks, they need to enforce GCability.

Should we not decide the angels atop pin headcount first?

I cannot believe the nonsese into which language lawyers forgetting they are endineers get themselves.

> 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,

Dude. They are INSIDE a MOP that frets over IES leaks, they need to cope.

or even to test whether
any method or gf exists specialized on that EQL object.

OK, I see. We are not in Kansas anymore.

I gotta say, no longer interested until the OP offers motivation for their concerns.

One thing we know in programming is that the abstract is largely unaddressable. bring me a sensible use case and I can help you.

Given that the OP has disappeared, i think this wise.

-hk

Kenneth Tilton

Fort Lauderdale, FL

http://tiltontec.com

"In a class by itself." -Macworld