[racket-dev] [plt] Push #24906: master branch updated

From: Ryan Culpepper (ryan at cs.utah.edu)
Date: Mon Jun 25 23:21:39 EDT 2012

On 06/25/2012 09:04 PM, Asumu Takikawa wrote:
> On 2012-06-25 20:17:33 -0600, Ryan Culpepper wrote:
>> IIUC from your later message, you've implemented the generics
>> analogue of object/c (per-instance contract), whereas
>> prop:dict/contract is closer to class/c (per-type contract). It's a
>> little fuzzy because prop:dict/contract hacks in per-instance
>> contracts too in a kind of ad hoc way.
> That's a good point. The better analogy might be interface contracts vs.
> class/c. With generics, it is easy to control all points that an
> instance is created since constructors are just procedures. With
> classes, you can't get away with that since the instantiation forms are
> macros.
> The difference/advantage you might get with a per-type contract for
> generics is that you get a more interface-like blame story, as with
> interface contracts. Coverage isn't as much of an issue since you can
> just contract all constructors.
> Unfortunately, it's also not clear how to implement interface-like
> contracts for generics. Since the generics forms don't control the
> constructors, it's not obvious how to instantiate the blame at the
> construction site.

You don't want to blame the construction site; the relevant party is the 
implementation site, where the generic interface is associated with 
concrete methods within a 'struct' form. See the docs for 
'struct-type-property/c' for an example.


Posted on the dev mailing list.