[nahiluhmot]

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 versions of Ruby.

* Perhaps allow the user to enable/disable type checking at a global/class level. For example, then users could only enable type checking during specs if they wanted.

* Instead of using class-level variables, try using class level instance variables. They have less odd behavior when dealing with subclasses [1].

[0] https://github.com/gogotanaka/Rubype/blob/develop/lib/rubype...

[1] http://www.sitepoint.com/class-variables-a-ruby-gotcha/

Edit: Whitespace

[riffraff]

there are respond_to? constraint, the first example is

    typesig :sum, [:to_i, Numeric] => Numeric

notice the :to_i

also, the global switch is simple:

    if $DEBUG
      require 'rubype'
    else
      def typesig(*args) end
    end

:)

[saraid216]

> 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 across the internet; people who only know about this project through GitHub would not see your comments either.

[jrochkind1]

What are you suggesting, that there never be any discussion of code that lives in a github repo on HN, but instead all discussion take place... in the GH issues?

[saraid216]

Yes.