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

On Fri, Apr 27, 2012 at 1:27 PM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:
> On 2012-04-27 13:17:36 -0500, Robby Findler wrote:
>> 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.
>>
>> [...]
>>
>> Or is there something else going on there that I'm missing?
>
> The primary reason that I added opaque contracts is that they are needed
> for Typed Racket's eventual class/object support.
>
> A secondary reason is for enforcing contract coverage. You're right
> though: you could get around this by writing a loose contract or by
> only specifying the name.[1] The intention is that the contract error
> would encourage people to write useful contracts (my mistake for saying
> "force"---it doesn't quite do that) rather than just bypass it.
>
> [1]: e.g., (class/c #:opaque m) will allow
>     (class object% (super-new) (define/public (m) ...))

I think that maybe I still misunderstand? Specifically, if I put an
opaque object contract on a value and the contract does not mention
'm', then (send ... m) will be a runtime error, but the current
contracts if I don't mention 'm' then it is just as if I had added the
unconstrained-domain-> contract on it?

So, if that's the difference, then what would be the difference of
making the class/c contracts for the GUI transparent? It sure seems
like we want to actually have all of the methods with contracts and,
if the previous paragraph is right, then there would be no difference
between opaque and transparent?

Sorry-- I think I'm missing something about this.

Robby