Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They behave enough like types that the library in question is pretty much as far from idiomatic Ruby you get if you use it like in his examples and tutorial.

Constraining inputs to a specific class, for example is a huge, giant no-no. If you're going to make Ruby statically typed, then you're better off picking a language that's easier to make fast.

This is a pet peeve of mine as I've more than once had to work around arbitrary, stupid checks against specific classes in cases where meeting the "actual" contract of the method called would be down to implementing a simple method or two.

The tutorial hints at some possibly Ruby-ish possibilities, like contracts based on whether an object responds to a method, but all the focus seems to be on class comparisons.

I do like the idea of specifying contracts, fwiw, as long as they're focused on behaviour and not on matching specific classes.

I don't, however like the idea of specifying them in the class files. Specifying them in separate files, that could be loaded when wanted, and that could also be used by a testing app to do some degree of automated testing of limits etc., or by other apps to do limited static analysis would be interesting.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: