[armedbear-devel] A clos patch for review

[Ville Voutilainen]

2009/7/28 Peter Tsenter <ptsenter at hotmail.com>:
> Question: how do you explain why the patch does not catch
> reinitialize-instance.error.1? How does this case differ from the other 3?

This seems to be related to eval. The make-instance form in
reinitialize-instance.error.1 fails
correctly when run directly, but when it's done inside eval, it doesn't fail.

Investigations continue..

Btw, I do think that the initarg-check is going to the right
direction, because I was able to
fix CHANGE-CLASS.ERROR.4 by merely adding a symbolp test to valid-methodarg-p.

I also have a fix for SHARED-INITIALIZE.ERROR.4, which doesn't cause regressions
in other tests. That fix is a bit odd, because it requires that
initform of (nil foo) is accepted,
but something like ('(abc) foo) is not.  The thing is, I have to test for
(and initarg (not (symbolp initarg)))
in std-shared-initialize, which checks that an initarg name must be a symbol
(so things like :foo and :bar work) but it can also be nil. The nil
case is quite curious.
If it's not handled, CLASS-14.1 will fail. That test is

(deftest class-14.1
  (let ((c (make-instance 'class-14 nil 'x)))
    (s1 c))
  x)

That seems to be because there's an :initarg nil in the defclass. The class is

(defclass class-14 ()
  ((s1 :initarg nil :reader s1)))

Any comments?