31–40 of 43 posts
This is very similar to contracts.ruby, which is cool. I'd love for more contract discussions. https://github.com/egonSchiele/contracts.ruby
It's much easier to use defensive coding techniques at runtime without having yet another framework in there that anyone who wants to read the code has to learn. Typing a few lines less is not really a benefit when it basically increases code complexity.
Really cool idea! I like that you can specify a `#respond_to?` constraint instead of a class. Not sure if OP is the author, but here's some feedback: * It would be better if this didn't pollute the global namespace by defining `#typesig` in `Module` [0] -- perhaps consider refactoring that method into a module which the user may extend. Doing so would also get you out of needing to define `Module#prepend` for older v…
> Not sure if OP is the author The OP is eduardordm, which can be found right underneath the article link. If you look on his HN profile, his GitHub name is also eduardordm. The repo author is gogotanaka. So, no. He's not. And the repo author is consequently unlikely to ever see your comments. Not only are these simple checks to make, but it's extremely bad practice to scatter commentary about a project everywhere ac…
This is very similar to contracts.ruby, which is cool. I'd love for more contract discussions. https://github.com/egonSchiele/contracts.ruby
Personally I don't get contracts when they aren't used for static verification. It's much easier to use defensive coding techniques at runtime without having yet another framework in there that anyone who wants to read the code has to learn. Typing a few lines less is not really a benefit when it basically increases code complexity.
A lot of languages (Java, C#, Go, etc.) have very inexpressive type systems, and that tends to make many dynamic language developers wary of them. Contracts has a very expressive type system though. It understands duck typing, adhoc union types, and a bunch of other stuff that makes it a great fit for a dynamic language.
Plus, we've disabled it in production, so we get coverage in test/development mode, but no performance penalty in prod. I look at it as an extended form of testing. Type contracts are very quick and easy to add, and they help tests catch additional errors. They're also useful in code reviews. Sometimes I'll have to search for 5 or 10 minutes to figure out what kind of thing is getting passed in, where the contract makes it perfectly clear.
The best part is that the contracts are optional. If some method takes wildly differing arguments and it's going to be a pain to give it a contract, then don't.
This is the best tool I've added to my Ruby arsenal in some time. I strongly recommend taking it for a spin.
Since I still like ruby's syntax, my hopes are that crystal (http://crystal-lang.org/) will one day become more mainstream (and maybe be adapted to some extent in mainstream ruby).
Earlier quoted context omitted.
Personally I don't get contracts when they aren't used for static verification. It's much easier to use defensive coding techniques at runtime without having yet another framework in there that anyone who wants to read the code has to learn. Typing a few lines less is not really a benefit when it basically increases code complexity.
The Contracts gem is very easy to use. I introduced it at work recently, and everyone got the hang of it in about 20 minutes. A lot of languages (Java, C#, Go, etc.) have very inexpressive type systems, and that tends to make many dynamic language developers wary of them. Contracts has a very expressive type system though. It understands duck typing, adhoc union types, and a bunch of other stuff that makes it a great…
What I meant was that contracts in a language like C# give me the ability to statically verify the program at compile time. It is not a "nicer way to add conditional testing logic" but a way to formally prove correctness in my programs.
Earlier quoted context omitted.
> When most practitioners think of "typechecking", they typically think about proving properties about programs statically. This project seems equivalent to adding a runtime check at each call site to ensure the arguments and return values are the correct type. It basically seems equivalent (albeit somewhat nicer in a few ways, ie. scalar types are supported) to PHP's "type hinting"[0]. I will say that it is useful,…
editor support for php type hinting and phpdoc method comments goes a long way. intellij can do significant refactors and and searching. you'll get real time feedback for violating types. it's not quite the same as a explicit compile step but pretty close
Earlier quoted context omitted.
The Contracts gem is very easy to use. I introduced it at work recently, and everyone got the hang of it in about 20 minutes. A lot of languages (Java, C#, Go, etc.) have very inexpressive type systems, and that tends to make many dynamic language developers wary of them. Contracts has a very expressive type system though. It understands duck typing, adhoc union types, and a bunch of other stuff that makes it a great…
I think you misunderstood me. What I meant was that contracts in a language like C# give me the ability to statically verify the program at compile time. It is not a "nicer way to add conditional testing logic" but a way to formally prove correctness in my programs.
In some cases, sanity checking can happen up front/at compile time. In other cases, these must occur at runtime.
The Pragmatic Programmer has a whole section on contracts; it is pretty good.
Any now and then another language get some sort of type check, why we don't build an agnostic type checker ? Then we interface with the AST of any language and we can stop re-iventing the wheel every two week... It is so crazy ? Nobody tried it before ?
Think about it, how would you handle type annotations in an agnostic type checker?