> As Dan points out, the main thing we give up by backing off from these > interfaces is the static typing; we don't get to use `IdentityObject` as a > parameter type, return type, or type bound. And the only reason we've come > up with so far to want that is a pretty lame one -- locking.
During our various discussions, we've also used `IdentityObject` and `ValueObject` as constraints in the t-vars / parametric VM proposal to address methods that are only partially applicable. We've also talked about using that as a signal to allow locking and other identity-operations to compile inside generic code that we can statically know won't have to deal with values. Does giving up on having VO/IO in the type system change our approaches to either the parametric vm future or identity operations in generic code? It sounds like we're willing to give up on the second but I don't have a good sense of what this does to the parametric VM. --Dan
