>An updater of a child record type should not have to deal directly
>with updating the fields of its parent (because would breach an
>abstraction barrier); instead, an updater of a child record type
>should call a corresponding updater for a parent record type.

I think this might not be possible in the general case. Or, rather,
it might depend on whether we want "non-virtual" or "virtual"
inheritance in r7rs-large.
(Not sure "virtual" is the correct term.)

A (very contrived) counterexample would be a struct which describes a
point on a plane
which has coordinates X and Y, but cannot leave a disc of radius R
with the center in some point X_0, Y_0.
There might be some algorithms which work with such a point.
R, X_0, Y_0 are set at construction only, X and Y have set-X! and set-Y!
Imagine drawing the bottom of a cup standing on a table.

Now we want to extend this point to work on a certain Z(X,Y) curve,
parameterised by the length of the segment ɑ.
Imagine lifting a cup off the table and placing it at some other point
on the table,
the bottom of the cup is the original struct.

We want the algorithms to keep working for the "bottom of the cup",
and the X²+Y² <R²  to be
preserved. But in order to describe this case, the method set-ɑ! of
the child object would
necessarily have to mutate X_0, Y_0, X, Y (but not R).

I understand that this example is very contrived, but I really suspect
that restricting a child's access to
parent's protected fields is unnecessarily limited.

On Mon, 31 Oct 2022 at 18:53, Marc Nieper-Wißkirchen
<xxxxxx@gmail.com> wrote:
>
> Am Mo., 31. Okt. 2022 um 11:18 Uhr schrieb siiky <xxxxxx@net-c.cat>:
> >
> > If I understood correctly, I believe the CHICKEN egg typed-records[0]
> > has just that feature.
> >
> > (defstruct foo x y z)
> >
> > This defines a type `foo` with fields `x`, `y` & `z`. Other than the
> > constructor, getters, and setters, it creates also an `update-foo` that
> > works like this:
> >
> > (let* ((foo (make-foo x: 1 y: 2 z: 3))
> >        (foo (update-foo foo x: 4)))
> >   (foo-x foo)) ;=> 4
>
> This is easy to define (in some form syntactically supported by
> standard Scheme); however, it is not a general approach for general
> record types because it is not type-safe (in the sense of invariants
> that may not be preserved).
>
> Conceptually, there is a subclass of all record types, namely those
> that basically model a set of independent fields given a type; for
> these, the Chicken approach makes sense.

--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)