[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Opacity considered harmful [was Re: Revised SRFI-76 (R6RS Records) draft]

This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.

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.

Sealed types and opaque records seem very similar to final classes and
private members from the Java world. I have never had *any* benefit in
my professional programming work from sealedness/finality, nor from
opacity/privateness; quite the opposite: every time I have even
*noticed* that something is either final, or private, it has been
because I'm trying to correct for an error in some library code or
trying to extend it in some direction unforeseen by the author. (A
similar objection applies to non-virtual methods in languages like C#.)

Sealedness and opacity have given me nothing but trouble, and have on
occasion cost my clients real money.

Just a thought!


PS: Opacity can be recovered in Scheme, should it be absolutely
necessary, by building capabilities out of lambdas.