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

[Kenneth Tilton]

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

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


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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20141226/bb1e5942/attachment.html>