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

[Kenneth Tilton]

Why is there no way to remove an interned EQL specializer meta-object? They
get defined in the context of a method definition, 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.

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.

On Fri, Dec 26, 2014 at 11:58 AM, Steve Haflich <shaflich at gmail.com> wrote:

> Scott (long time no see):
>
> This reply doesn't seem correct at all.  Interning an EQL specializer
> does not directly have anything to do with methods (although it is
> most often performed by the implementation when an EQL method is
> defined) nor would  methods be remembered in the hash table or
> whatever the implementation uses to intern them.
>
> An EQL specializer must exist in order for METHOD-SPECIALIZERS to have
> something to return, and as an argument to be passed to functions like
>  SPECIALIZER-DIRECT-GENERIC-FUNCTIONS
>  SPECIALIZER-DIRECT-METHODS
>  EQL-SPECIALIZER-OBJECT
>
> Specializers are also necessary if one wants to manipulate generic
> functions and methods directly using the MOP instead of with the
> DEFGENERIC and DEFMETHOD macros.  If for no other reason, specializers
> exist because the MOP must be self-reflexive.
>
> True, there is no way to remove an interned EQL specializer, which may
> be an oversight in the MOP.  But there will be exactly one entry for
> each unique specializer in the EQL hash table or whatever else is used
> for their internment.  I suppose an implementation that features weak
> hashtables could use one for EQL specializers, since if there were no
> other references to one there would be no portable way to ask if it
> was still there.
>
> "Growing without bounds" is no different than what happens when a new
> symbol is interned, or a new function or method is defined on an
> interned symbol.  Rarely any problem in typical programming.
>
> On Fri, Dec 26, 2014 at 7:38 AM, Scott McKay <swmckay at gmail.com> wrote:
> > The specializers are probably interned for the sake of allowing
> > better optimization of EQL dispatch. I don't think it'll grow without
> > bounds; it probably gets big enough to hold all of the methods with
> > EQL dispatch, and then grows no further.
> >
> > Honestly, I don't use EQL methods much myself, if they can be
> > avoided by using SELECT.
> >
> > --S
> >
> >
> > On Fri, Dec 26, 2014 at 10:33 AM, Kenneth Tilton <ken at tiltontec.com>
> wrote:
> >>
> >> Not sure where I see either "forever growing" or "memory leak". Come to
> >> think of it, not sure what you mean by "mandatory". It is a spec of how
> the
> >> MOP should work internally. Do you have some other way in mind for
> things to
> >> work?
> >>
> >> I mean, it sounds like you might be talking about forever adding and
> >> removing eql-specialized methods, but I'd rather not guess. Even if so,
> >> nothing stops the implementation from GCing unused specializer
> metaobjects.
> >>
> >> -hk
> >>
> >>
> >> On Fri, Dec 26, 2014 at 2:10 AM, Jean-Claude Beaudoin
> >> <jean.claude.beaudoin at gmail.com> wrote:
> >>>
> >>> Hello CL Pros,
> >>>
> >>> Lately I have been improving the MOPishness of MKCL and that brought me
> >>> in contact with the specification of intern-eql-specializer in AMOP.
> >>>
> >>> The EQ requirement on its returned value seem to me to dictate a
> >>> hash-table implementation (PCL and its derivatives all seem to do just
> >>> that).
> >>>
> >>> The problem I see with this is that it will be a "for ever growing"
> >>> hash-table with not upper bound in sight. And the "purpose" of such a
> >>> mandatory built-in memory leak also completely escapes me. Could any
> of you
> >>> share some insight on this question, please?
> >>>
> >>> Thank you,
> >>>
> >>> JCB
> >>>
> >>>
> >>> _______________________________________________
> >>> pro mailing list
> >>> pro at common-lisp.net
> >>> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
> >>>
> >>
> >>
> >>
> >> --
> >> Kenneth Tilton
> >> Fort Lauderdale, FL
> >> http://tiltontec.com
> >> "In a class by itself." -Macworld
> >>
> >>
> >>
> >> _______________________________________________
> >> pro mailing list
> >> pro at common-lisp.net
> >> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
> >>
> >
> >
> > _______________________________________________
> > pro mailing list
> > pro at common-lisp.net
> > http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
> >
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/pro
>



-- 
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/829fab2d/attachment.html>