Odd that the paper you chose to link to is one specifically addressing a difficulty integrating the ideas with Java's class hierarchies -- while the broader subject may be relevant to Go, I don't think that paper is.
Wrt Dan's question of doing static checks, I'll quote the paper: > In principle, one could try to prove the correctness of behavioral > contracts. For example, the Extended Static Checking group at > Digital has developed verification tools for Java and Modula 3 [3]. > In general, however, the languages used to express behavioral con- > tracts are rich enough that it is not possible to verify statically > that the contracts are never violated. So it's not talking about a compile-time mechanism. To make Tamas's idea work you'd need to (a) have numbers encoded in the type system somehow, and (b) actually be able to relate them to the size of the arrays. You can do this with dependent types, but integrating those into a practical programming language is still a very open research topic. You can hack around this in some circumstances; there are tricks you can play to represent numbers at the type level in a somewhat limited, clumsy way. But most of the trickery I've seen relies on one feature or another that Go doesn't have, and the result is always somewhat cumbersome. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
