[racket-dev] Class contracts: opaque or transparent?

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