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

I'm not seeing why a notion of "opaque" like this is valuable, but
maybe I don't understand what s going on. Specifically, it seems like
I can add the contract (unconstrained-domain-> any) to each method to
get it to be opaque without actually contributing anything of value.
It seems better to let the programmer just not say anything instead of
making them do the busywork of adding that annotation on each method.

Or is there something else going on there that I'm missing?

Robby

On Fri, Apr 27, 2012 at 12:48 PM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:
> 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