On Mon, Oct 24, 2016 at 8:34 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

This (the parent accessor can access the payload of a subtype) is certainly what is needed for using this SRFI in the real world. For example, it would be impossible to implement a record-type system à la SRFI 131 and 136 on top of SRFI 137 if it didn't provide this.

N.B.: For demonstration purposes, the current "reference" implementation of SRFI 136 is now built on top of SRFI 137 (with parent accessors being able to access payloads of subtypes).

 

On reflection, I think it has to do both: a base-type accessor should be able to access the payload of an object of a derived type, and a derived-type accessor should be able to access the payload of an object of the base type.  No?

On first sight, this looks a bit smelly to me, and it may be bad when it comes to encapsulation requirements. I also don't think that it is really needed because the code defining the parent type can export a well-defined interface that client code can import to access a parent instance's payload.

Or do you have an application in mind where this wouldn't suffice?

Marc

 

-- 

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org

Newbies always ask:

  "Elements or attributes?

Which will serve me best?"

  Those who know roar like lions;

  Wise hackers smile like tigers.         --a tanka, or extended haiku