Re: Slot accessing issues in EIEIO

[Zhu Zihao]

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?