On Fri, Dec 26, 2014 at 10:10 PM, Steve Haflich <shafl...@gmail.com> wrote:
> 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. 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*
_______________________________________________ pro mailing list pro@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro