Tony Garnock-Jones wrote:
> Michael Sperber wrote:
>> Without opacity and with reflection, a client who
gets its hands on a
>> record can get at its fields, thus breaking the
abstractions provided
>> by the maker of that record.
>
> I see this as an unqualified benefit. [...]
> Sealedness and opacity have given me nothing but
trouble, and have on
> occasion cost my clients real money.

This sort of dilemma usually tells me that one should
think of
other alternatives. So how about this one?:

Provide opaque records but also provide clients with a
mechanism to get to the internal structure by force.
Ideally, the mechanism is highly visible
(syntactically), and too inconvenient to use 'by
accident'.

A minimal design for this proposal is adding
procedures
    IGNORE-OPACITY-RECORD?
    IGNORE-OPACITY-RECORD-RTD

So the final choice is with the client: Respect
opacity, or ignore it.

(The only compelling reason I see to have the final
choice with
the designer of the record type is security, and I
agree with
Mike that SRFI 76 is not the beast to send into that
arena.)

Sebastian.