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.
> 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 [...] > > Sealedness and opacity have given me nothing but trouble, and have on > occasion cost my clients real money. I myself have done quite a bit of work as a contractor maintaining applications written in Java, and I have also seen the overuse of opacity -- as well as the underuse of other design patterns such as removing code duplication, or using a functional approach for parts of code which do not need to be stateful. In the code I was working with, this overuse of opacity seemed to me to be the natural result of how the original programmers had been managed. Each had been given a piece of the project to work on, each didn't want to be blamed if something went wrong, and issues such as overall code quality -- or how well the program would actually work when the pieces were put together -- were left by management to another day. Ever though the overuse of opacity made future integration, enhancement, or repair of the code more difficult, that cost was not borne by the original programmers. Instead, like you say, the cost was later paid by management. Opacity, like any tool, can be overused, while still remaining a useful tool. Opacity is a kind of assertion: that only code within this boundary accesses an internal implementation. Assertions can make code easier to understand and reason about, and thus easier to enhance and debug. But only if used wisely, of course. I've seen plenty of code with lots of code duplication, no clear abstractions (i.e. a bunch of classes, but no reason for code to be in one class instead of another), and it all covered in a spray of random "private" and "final" keywords! I do think that this SRFI does take the right approach in making non-opaque the default. Thus on the issue raised in the SRFI: > Record types defined via the syntactic layer default to > non-opaque. Should they default to opaque instead? I would argue no. Andrew Wilcox