[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49291: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instanc
From: |
Stefan Monnier |
Subject: |
bug#49291: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform |
Date: |
Wed, 30 Jun 2021 15:13:37 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> 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
bug#49291: [akater] Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform, akater, 2021/06/30
bug#49291: [akater] Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform, Stefan Monnier, 2021/06/30