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

Previous Next

Full log

Message #20 received at 49291 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: akater <nuclearspace <at> gmail.com>
Cc: 49291 <at> debbugs.gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 15:13:37 -0400

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.