bug#49291: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform

[Stefan Monnier]

> There are iusses, some stylistic, some related to comments in the code.
> - There is a comment here:
>> First, see if any of our defaults are `lambda', and
>> re-evaluate them and apply the value to our slots.
> I don't observe anything like this happening.  Looks like it refers to
> eieio-default-eval-maybe (likely referring to any compound form with
> fbound car as to `lambda') which used to be in eieio-core in 27 but now
> is gone.

I think it's called `eieio--eval-default-p` nowadays.

> Maybe we should drop this comment?

Indeed, thanks.  `eieio--eval-default-p` is not used here any more
(it's only used in `defclass` (and its corresponding function) nowadays).

> - There is a comment:
>> For each slot, see if we need to evaluate it
> Slots are self-evaluating objects; I think it was meant to be “to
> evaluate its initform”.

LGTM, thanks.

> - There is FIXME
>> FIXME: We should be able to just do (aset this (+ i <cst>) dflt)!
> Local variable dflt had been removed after Emacs 27 release.  The
> comment should likely have been gone too, or at least updated.  It
> suggests to assign the value of initform with a low-level `aset' applied
> to eieio--class struct

No, not to the eieio--class but to the new object.
Basically replacing the `eieio-oset` with `aset`.  This is because the
vector returned by `eieio--class-slots` should contain the slots info in
the same order as the slots themselves are found in the actual object so
we don't need to ask `eieio-set` to find the slots's position in
the object.

> - I employ when-let which requires subr-x at compile time.  I can't
> check the build cleanly right now, only with some dirty reverts related
> to libseccomp issues but aside from that, this subr-x dependency doesn't
> break byte-compilation of eieio.el.  I hope it's fine?

That Looks fine, thanks.
But could you add a test or two to
test/lisp/emacs-lisp/eieio-tests/eieio-tests.el ?


        Stefan