[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Opacity considered harmful
- To: srfi-76@xxxxxxxxxxxxxxxxx
- Subject: Re: Opacity considered harmful
- From: Andrew Wilcox <awilcox@xxxxxxxxxxxxxxxxx>
- Date: Sat, 7 Jan 2006 11:31:19 -0500
- Delivered-to: srfi-76@xxxxxxxxxxxxxxxxx
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=YkoVIOA5feZWkNsnaUJqiGRTivzEfHVmw/9no1tmyuXGMz8ecXNOMOzxadT3tAmtKHoBA7H5S/TnTafc2dyzQo/AU16PiSd5qnTDxX8J2MfqjPxP3ah7ZundCLe8ie7WUEW/zG1xPzJLFO1VJL2X/956KcTL35TgQLR/B7zIn2w=
- Sender: andrew.wilcox@xxxxxxxxx
> 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
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
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.