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
