Re: Slot accessing issues in EIEIO

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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