From: Zhu Zihao <all_but_last@163.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Jonas Bernoulli <jonas@bernoul.li>,
Zhu Zihao <all_but_last@163.com>,
emacs-devel@gnu.org
Subject: Re: Slot accessing issues in EIEIO
Date: Fri, 08 May 2020 11:12:36 +0800 [thread overview]
Message-ID: <87wo5nf7bv.wl-all_but_last@163.com> (raw)
In-Reply-To: <jwvpnbf3jo7.fsf-monnier+emacs@gnu.org>
On Thu, 07 May 2020 22:52:26 +0800,
Stefan Monnier wrote:
>
> > That sounds too complicated for my use-cases at least,
>
> Maybe it would require a fair bit pf change, but I don't see why it
> would be significantly more complicated than what you currently do if
> you were to start from scratch with such a design (to clarify: I'm
> mostly interested in making sure that we have a good solution for
> someone who wants to do that and is starting from scratch; having a good
> solution for the existing closql.el is a somewhat secondary concern
> since the advice mechanism does the job).
>
> You can structure the two-objects solution in various different ways:
> e.g. you could keep your objects as they are, but create
> a "proxy/firewall/interposer" object which contains only a single field
> (which points to the real object). Then when accessing fields of this
> object you can use the `slot-missing` generic function to do what your
> current advice does, simply operating on the underlying real object.
>
> It should be possible to create a "generic interposer" solution like
> that which can be used instead of your advice and that is not specific
> to closql.
>
> > and I don't see what we gain by doing that except not having to advice
> > `eieio-oref' and `eieio-oset', which by the way I don't think is all
> > that horrible.
>
> Advising `eieio-oref` means slowing down every access to every slot of
> every EIEIO object. That's the main problem for me. For some EIEIO
> uses it's not a problem, but some EIEIO uses do care about the
> performance of accesses to their slots.
>
> > I would have liked to write
> >
> > (cl-defmethod eieio-oset ((obj closql-object) slot value)
> > ...)
>
> We could go there, but there's again an issue of performance:
>
> A) We could keep the code as is and just turn the `defun` into a `cl-defgeneric`,
> in which case performance will be unaffected *until* someone comes
> with his own `(cl-defmethod eieio-oref ...)` at which point again all
> accesses to all slots of all EIEIO get impacted (if there's only one
> (default) method, cl-generic optimizes away the method dispatch).
>
> The advantage compared to your advice is that subsequent
> `(cl-defmethod eieio-oref ...)` don't impose additional slowdown
> (unless they dispatch on another argument).
>
> B) We could try and work harder in the implementation of `eieio-oref` so
> that the added cost discussed in (A) is always present but is made
> useful (by reducing the rest of the cost). This would likely require
> changes in cl-generic.el as well.
> Currently eieio-oref basically does a gethash to find the slot's offset
> and then an `aref` to get the slot's content. The method dispatch
> adds another gethash, so we'd want this dispatch-time gethash to
> replace the one that fetches the slot offset.
> This would be great, but it requires a good bit more work.
>
>
> -- Stefan
It looks like a diffcult job. Maybe we can fix the eieio pattern of pcase.
In this piece of code:
(defclass test-class () ((slot)))
(pcase (make-instance 'test-class)
((eieio slot)
slot))
;; => unbound
An unbound marker will be returned on the fly without running slot-unbound
in pcase with eieio pattern. Is it reasonable?
next prev parent reply other threads:[~2020-05-08 3:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 4:17 Slot accessing issues in EIEIO Zhu Zihao
2020-05-06 13:28 ` Stefan Monnier
2020-05-06 14:28 ` Zhu Zihao
2020-05-06 21:58 ` Stefan Monnier
2020-05-07 3:20 ` Zhu Zihao
2020-05-07 3:39 ` Stefan Monnier
2020-05-07 4:00 ` Zhu Zihao
2020-05-07 4:55 ` Zhu Zihao
2020-05-07 12:11 ` Stefan Monnier
2020-05-07 14:13 ` Jonas Bernoulli
2020-05-07 14:52 ` Zhu Zihao
2020-05-07 14:52 ` Stefan Monnier
2020-05-08 3:12 ` Zhu Zihao [this message]
2020-05-08 3:48 ` Stefan Monnier
2020-05-08 9:12 ` Zhu Zihao
2020-05-08 15:09 ` Stefan Monnier
2020-05-07 12:15 ` Stefan Monnier
2020-05-07 14:16 ` Jonas Bernoulli
2020-05-07 13:44 ` Jonas Bernoulli
2020-05-08 2:09 ` Stefan Monnier
2020-05-06 15:44 ` Jonas Bernoulli
2020-05-06 15:56 ` Stefan Monnier
2020-05-06 16:43 ` Jonas Bernoulli
2020-05-06 17:06 ` Eric Abrahamsen
2020-05-07 19:32 ` Daniel Colascione
2020-05-06 15:40 ` Jonas Bernoulli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wo5nf7bv.wl-all_but_last@163.com \
--to=all_but_last@163.com \
--cc=emacs-devel@gnu.org \
--cc=jonas@bernoul.li \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).