🚀 go-pugleaf

    Date: Thu, 16 Apr 1992 15:53 EDT
    From: Thomas Kirk <tk@HUNNY.research.att.com>

	From: Barry Margolin <barmar@Think.COM>
	Subject: Re: no-applicable-method
	To: tk@research.att.com
	Cc: mh5l+@andrew.cmu.edu, comp.lang.clos@cis.ohio-state.edu
	In-Reply-To: <19920416170513.9.TK@PETZL.research.att.com>
	Message-Id: <19920416182843.6.BARMAR@occam.think.com>

	    Date: Thu, 16 Apr 1992 13:05 EDT
	    From: Thomas Kirk <tk@HUNNY.research.att.com>

	    this will work fine. assuming that you can get at the generic functions,
	    just change the class of the generic function object, like so:

	Sorry, this isn't permitted.  According to p.197 of "The Art of the
	Metaobject Protocol", third paragraph, "the class of a generic function
	metaobject may not be changed...".

    true enough. however, given that (a) this is a useful thing to do,
    and (b) many extant CLOS implementations allow it, it may be worthwhile 
    to relax this restriction. it's in the spirit of the specification in 
    the AMOP to consider such improvements, unless there's some convincing 
    rationale for leaving it alone (perhaps there is, but i can think of 
    no reason myself).

I can't find where AMOP specifically states this restriction (the place
I quoted actually says, "*since* the class of a generic function may not
be changed").  But I believe the intent is to permit implementations to
make compile-time optimizations of calls to standard generic functions
and other implementation-defined generic function classes.  Changing the
class of a generic function would invalidate these optimizations.

                                                barmar