Hi all,
Recently I have been adding class contracts to parts of the GUI system.
In tandem, I've also added a new feature to `class/c` that allows a
contract to be opaque, which means that the contract requires that *all*
public methods & fields in the contracted class are themselves
contracted.
This raises a question: should the contracts that are applied in our
core libraries be opaque or transparent (status quo)?
Note: this is a question about coding practice rather than language
defaults. `class/c` will continue to be default transparent.
The main benefit that I see for class contracts being opaque:
* Enforces contract coverage: if a new public method/field is added
to the implementation, the class contract will force the implementor
to add a corresponding method/field contract (or at least specify
its existence).
You could also see this with a less strict connotation as helping you
figure out your contract coverage.
Possible counter-arguments:
* Composability: opaque class contracts are not composable since each
one requires the entire specification. This shouldn't be a problem
since the individual class/c clauses can be composed/reused (e.g., ->m
contracts).
* Do we want contracts on all methods & fields?
Any thoughts?
Cheers,
Asumu
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
