Am Mo., 31. Okt. 2022 um 13:54 Uhr schrieb Vladimir Nikishkin
<xxxxxx@gmail.com>:
>
> >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.)

We must be careful with these terms coming from a classical OOP model
like C++ or Java.  As I explained in [1], the record system of Scheme
is much simpler and does not implement OOP (but can be used to
implement an OOP layer).

> 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.

The values R, X_0, Y_0 are meant to be constants outside the record, are they?

>
> 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.

I fear I don't understand your example in detail so that I could give
a satisfactory answer.  Could you redescribe your model, e.g. with
some Scheme code and with less "imagination"? :)

--

[1] https://srfi-email.schemers.org/srfi-237/msg/20934836/