First, I'm not against incremental changes, I'm for all the way.
Second, we're not talking about entire clos, but a very specific problem. This problem is not unique for clos, but just heavily used by it.
What I'm afraid of is there is a more fundamental issue here and this patch makes it even more hidden.
BTW, ANSI standard does not allow &aux in generic functions (sec 3.4.2), but this version of clos treats it as a legitimate citizen.
Question: how do you explain why the patch does not catch reinitialize-instance.error.1? How does this case differ from the other 3?
Date: Tue, 28 Jul 2009 01:37:13 +0300 Subject: Re: [armedbear-devel] A clos patch for review From: ville.voutilainen@gmail.com To: ptsenter@hotmail.com CC: armedbear-devel@common-lisp.net
2009/7/28 Peter Tsenter ptsenter@hotmail.com:
The patch seems to produce a result as claimed. But it's not generic enough. It does not catch, e.g., defgeneric.error.20 nor reinitialize-instance.error.1, which follow the same pattern: supply bogus arguments in initargs. Introducing this patch might create an impression that such cases handled properly always.
Well, I'd rather do these fixes piecemeal than attempt to produce some perfect megapatch that fixes everything clos-related in a single sweep.
_________________________________________________________________ Bing™ brings you maps, menus, and reviews organized in one place. Try it now. http://www.bing.com/search?q=restaurants&form=MLOGEN&publ=WLHMTAG&am...