🚀 go-pugleaf

    From: Barry Margolin <barmar@Think.COM>
    Subject: Re: no-applicable-method

	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

it's explicit in the paragraph previous to the one you cited. you're 
undoubtedly correct about the supposed intent, which is why one wouldn't 
want to remove all restrictions on changing gf objects. a reasonable 
compromise, instead of prohibiting this outright, would be to put 
restrictions on the new generic function class, and constraints 
on what behavior can change as a result (e.g. out-of-band behavior
that depends on the gf class, like no-applicable-method). 

that several CLOS implementations already allow this is suggestive, 
but only CLOS implementors are likely to know for sure what the 
tradeoffs are.