Am Do., 3. Nov. 2022 um 03:12 Uhr schrieb Vladimir Nikishkin
<xxxxxx@gmail.com>:
>
> >The values R, X_0, Y_0 are meant to be constants outside the record, are they?
>
> Yes. The record describes a set of points around some point fixed at
> record creation time.
>
> >Could you redescribe your model, e.g. withsome Scheme code and with less "imagination"? :)
>
> Not sure I can do that with Scheme code.
> But what I am talking about is essentially "protected" in C++.
> When seen as an instance of the parent class A, the points X and Y
> obey an invariant.
> However, when class A is a parent class of some child class B, this
> rule becomes:
> X and Y obey an invariant, which is nevertheless different for each
> value of some Z defined in B, and this Z might be mutable.
> So when Z is mutated using set-Z! in the child class B, it has to
> change the invariant, which is impossible using only class A's public
> interface.
> (And also adjust X and Y, but that is doable using A's public methods.)

Thank you for your explanation.

If class A is semantically defined so that X and Y obey the original
invariant, then class B is semantically not a child of class A (if
class A models white mammals and class B models black cats, class B
cannot be semantically a child of class A).

So if you want class B to be a child of class A, the set of values
class A models has to be extended (and its invariant thus relaxed).

This is nothing particularly about Scheme, just about what is usually
understood by a type and a subtype (and applies equally to classical
OOP languages).

So what you can do is the following example:

(define-record-type base
  (fields x y invariant)
  (protocol
    (lambda (n)
      (lambda (x y invariant?)
        (assert (procedure? invariant?))
        (assert (invariant? x y))
        (p x y invariant)))))

(define-record-type simple-child
  (parent base)
  (protocol
    (lambda (n)
      (lambda (x y)
        (define invariant?
          (lambda (x y)
            (<= (+ (* x x) (* y y)) *radius*)))
        ((n x y invariant?))))))

(define-record-type complicated-child
  (parent base)
  (protocol
    (lambda (n)
      (lambda (x y z)
        (define invariant? ...)
        ...))))

Note that you don't have to export the base class from your module.
This allows you to somehow model the "protected" specifier of C++.

I am looking forward to your response,

Marc

> On Mon, 31 Oct 2022 at 21:09, Marc Nieper-Wißkirchen
> <xxxxxx@gmail.com> wrote:
> >
> > 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/
>
>
>
> --
> Yours sincerely, Vladimir Nikishkin
> (Sent from GMail web interface.)