From: Bruno H. <br...@cl...> - 2011-07-26 21:33:23
|
Sam, > I am thinking about replacing the %defclcs table with this: > > (defun find-common-subclass (s1 &optional (s2 'simple-error)) > (let (ret (c2 (find-class s2))) > (dolist (c (mop:class-direct-subclasses (find-class s1))) > (when (clos::subclassp c c2) > (when ret > (error (TEXT "~S and ~S have two common subclasses: ~S and ~S") > s1 s2 ret c)) > (setq ret c))) > (unless ret > (error (TEXT "~S has no common subclasses with ~S") s1 s2)) > (class-name ret))) > > I think this would be more robust than the current setup. > wdyt? You can certainly replace the CDR parts of that table using this function, and use that in the initialization of O(error_types). If you mean to remove O(error_types) entirely and replace the function convert_simple_condition with a call to find-common-subclass, then this would make clisp more fragile: 1) When a user defines a class through (defclass my-type-error (type-error simple-error) ...) then find-common-subclass will signal an error "... have two common subclasses ...". If you keep the error message, you are breaking ANSI CL (it allows the user to define my-type-error like this); if you remove the error message, you need better heuristics for finding the right subclass. 2) More generally, any breakage in the CLOS class hierarchy under ERROR could make it impossible to signal a plain error or type-error. You know that CLOS itself is complicated and may have subtle bugs. Also the users can modify the internals of classes through MOP functions and sys::%record-ref. If clisp gets into infinite recursions of internal errors after stupid manipulations of CLOS classes, I would dislike this very much. => Don't make the error handling more fragile. At some point it was possible to set the symbol-value of all non-constant symbols to NIL, and clisp survived this. To give you an idea of what kind of robustness I would expect. Bruno -- In memoriam Eva Perón <http://en.wikipedia.org/wiki/Eva_Perón> |