Oh, I see. Yes, this seems like a fine thing to me (making class contracts be opaque).
Robby On Fri, Apr 27, 2012 at 1:51 PM, Asumu Takikawa <as...@ccs.neu.edu> wrote: > On 2012-04-27 13:37:02 -0500, Robby Findler wrote: >> 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 > > The opaque class contract wouldn't produce an error on (send ... m) but > instead when the contract is applied to the class. It's just a first-order > check that makes sure that > "the set of contracted members" = "the set of class members" > >> So, if that's the difference, then what would be the difference of >> making the class/c contracts for the GUI transparent? > > If all methods have contracts, there is no difference at all. But > suppose that someone adds a new method and they forget to add a > corresponding contract. Opaque would then raise an error, transparent > would not. > > Sorry if I'm being unclear. Let me know if that clears it up. > > Cheers, > Asumu _________________________ Racket Developers list: http://lists.racket-lang.org/dev
