On 1/7/06, Tony Garnock-Jones <xxxxxx@kcbbs.gen.nz> 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.
>
> 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.
>

I absolutely and strongly support this!

Building up insurmountable walls to avoid peeking into data-structures
originates
in my experience mainly from psychological reasons, it's practical use
being minor or nonexistant. Reflection and transparent data, on the other hand,
have very much practical use, even if it's just for debugging.

cheers,
felix