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