Nathan Lilienthal

Adding `Contract` to the end of every contract seems overly verbose and likely to not be done, causing consistency problems. The ability to define a contract with any name (even...

Seems like a classic deprecation issue. We should defiantly deprecate the `include Contracts` behavior. I'd like to allow for that to stay be the main method of including, without a...

Well you see, it is possible. Though I'm not 100% sure we want to be doing it. ``` ruby def do_it(&block) new_block = proc do |s| old = s::Foo.send(:remove_const, 'VAL')...

It's either magic, strings, or explicit namespaces. Choose one.

Another huge point against the code I posted is thread safety. Which unless Ruby does something fancy I don't know about, will defiantly be broken in a horrific way by...

I'm always a fan of parsing things. So this might be my suggestion too. Stands to solve a lot of problems.

I personally do not like the `.>>` or `.

Agreed, as much as I'd love to write a parser. The more I think about it I'm starting to lean heavily to using `Contract Contracts::Num => Contracts::Num` and having a...

Maybe I'm just not following well, but I don't really like the idea of using `include Contract::Core` as the primary interface. I'd rather deprecate using things like `Num` without a...

Ok I see your point about the submodule. In terms of the aliasing, I'm starting to like the idea of not using `include` as the primary way of pulling contracts...