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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 49291 <at> debbugs.gnu.org
Subject: bug#49291: [akater] Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 14:57:52 -0400

[Message part 1 (text/plain, inline)]

[ Why, oh why, did I mistype this? ]

[Message part 2 (message/rfc822, inline)]

From: akater <nuclearspace <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 49291 <at> gnu.org
Subject: Re: [akater] [PATCH] lisp/emacs-lisp/eieio.el
 (initialize-instance): Fix initform
Date: Wed, 30 Jun 2021 16:44:12 +0000

[Message part 3 (text/plain, inline)]

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.  Maybe we should drop this comment?

- 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”.

- 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 but (1) I don't understand the + i shift (2)
eieio--class is not declared to be of :type vector, neither does it
inherit from a struct declared to be of :type vector.  I suggest to
replace the comment with
“TODO: maybe specify eieio--class as vector and use aset here”

- 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?

[signature.asc (application/pgp-signature, inline)]

[0001-lisp-emacs-lisp-eieio.el-initialize-instance-Fix-eva.patch (text/x-diff, attachment)]

Previous Next

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