[racket] Contracts on subclasses/mixins

Thanks. That's important because I do override a few methods. For example, set-cell! erases pencil marks and clear-cell! puts them back in. But in most cases the methods are not overridden. 

Sent from my iPhone

On Sep 10, 2012, at 1:23 PM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:

> On 2012-09-10 12:35:52 -0700, Gregory Woodhouse wrote:
>> Now, here's my question. provide grid% with its own contract-out
>> clause. It seems rather redundant (and presumably unnecessary) to
>> repeat the methods from base-grid% in the contract for grid%.
> 
> You don't need to repeat the contracts unless you actually override
> these methods. You can think of class/c contracts as being tied to
> a particular *implementation* of the method. If you don't
> re-implement the method, specifying extra contracts only serves to
> move around the responsibility for the implementation.
> 
>> My guess is that if I do not do this base-grid% will be blamed for any
>> contract violations in the base class rather than grid%. Is this
>> correct? Or will it even work? I don't mind if base-grid% is blamed
>> for the contract violation. In fact, it may be preferable because it
>> is more specific.
> 
> Yes, that should be correct. Here's a simple example that I think
> illustrates what you're talking about:
> 
>  #lang racket
> 
>  (define/contract c1%
>    (class/c [f (->m odd? odd?)])
>    (class object%
>      (super-new)
>      ;; broken method
>      (define/public (f x) 2)))
> 
>  (define/contract (mix base)
>    (-> (class/c)
>        (class/c [g (->m odd?)]))
>    (class base
>      (super-new)
>      (inherit f)
>      (define/public (g) (f 1))))
> 
>  (send (new (mix c1%)) f 2)
> 
> The method `f` is contracted only in the base class `c1%`.
> When invoking the method on the result of the mixin with
> a good argument, you get a contract violation blaming the
> method implementation in `c1%`.
> 
> If, instead, you had overriden `f` in the mixin, then the
> contract is not checked.
> 
> If it turns out that you want to say `f` should *always*
> be protected by some contract no matter who implements it,
> you might consider using an interface contract.
> 
> Cheers,
> Asumu