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! Regards, Tony PS: Opacity can be recovered in Scheme, should it be absolutely necessary, by building capabilities out of lambdas.