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 <as...@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 ____________________ Racket Users list: http://lists.racket-lang.org/users
