Subject: bug#66938: 30.0.50 [PATCH]: Make EIEIO :accessor behave like :reader when reading a slot's value

From: Stefan Monnier <[email-masked]>
Date: Wed, 29 Nov 2023 09:01:32 -0500

> Just wanted to say that while I think this is all very fine to
> improve on EIEIO's inaccurate emulation of CLOS, this breaks
> a lot of stuff, broke Eglot and Jsonrpc, immediately.
>
> This is mainly because EIEIO users like me got sloppy with
> their slot definitions and don't put explicit :initforms
> in them, instead relying on this quirk.

FWIW, I don't like the `slot-boundp` business and much prefer the
principle that if an application needs such a concept it should instead
treat nil as the "unbound" marker.

> Oh well, I'm fixing this now as part of bug#67480, but
> we should definitely expect flak more or less proportional
> to the use of EIEIO out there (and in here).

Hmm...

> BTW another reason I get sloppy is that EIEIO doesn't allow
> me to use a
>
> (some-slot :initform (error "required!") ...)
>
> like I do in CLOS.

I think this works nowadays (the expression is not evaluated in the
right context (it's evaluated in the empty context), but AFAICT it's
evaluated at the right time):

    (cl-defmethod initialize-instance ((this eieio-default-superclass)
    				   &optional args)
      [...]
          (let* ((slot (aref slots i))
                 (slot-name (eieio-slot-descriptor-name slot))
                 (initform (cl--slot-descriptor-initform slot)))
            [...]
              (eieio-oset this slot-name (eval initform t))))))
       [...]

-- Stefan