[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29220: 26.0.90; eieio-persistent-read fail to restore saved object.

From: Stefan Monnier
Subject: bug#29220: 26.0.90; eieio-persistent-read fail to restore saved object.
Date: Wed, 29 Nov 2017 10:15:28 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> That's exactly what Noam was saying! The implementation of objects
> changed from 25 to 26, and thus their printed representation also
> changed.

Indeed.  But the subject mentions "...eieio-persistent-read..." and
eieio-persistent was designed specifically to try and avoid dependence
on how Emacs represents EIEIO objects.  The problem here is that
eieio-persistent doesn't support hash-tables, so the EIEIO objects in
the hash-tables are printed with `princ` (i.e. in all their internal
glory) rather than going through eieio-persistent.

So I think the real fix here is to extend eieio-persistent with support
for hash-tables.

> The real problem isn't that objects written with 25 can't be read by 26
> (I don't think that kind of compatibility is guaranteed), but that
> objects written by 26 can't be read at all -- at least not when they're
> written internally, as members of other objects.

There are many different ways one might want to "print" objects,
depending on the intention:
- print for human consumption (i.e. eliding details to keep it concise).
  That's what cl-print aims for, for example (tho IIRC it doesn't
  support hash-tables either, so far).
- print in a way that can be read back in the future (possibly far
  future, where some details of the internal representation have
  changed).  This is what eieio-persistent aims for.
- print in a way that can be read back, preserving as many of the
  details as possible.  This is what `princ` aims for.  In the case of
  EIEIO objects, I'm not completely satisfied with the result in
  Emacs-26, but I think I'd rather live with it for now to get time to
  better understand the design space&constraints before we improve it.

-- Stefan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]