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>
|
