custom error formatter for KeywordArgs

[mindreframer]

problem:

• it is impossible to quickly understand the contract violation with big hashes

solution:

• provide custom error formatter just for keywordargs, that gives you extra information about:
• Missing Contract definition (for unspecified keys in contract)
• Invalid Args (validation failures)
• Missing Args (required values, that are missing)

[rous-gg]

This is a really good feature to have. Right now it's really hard to understand what is wrong with keyword args contract and you spend a lot of time making that diff in mind.

[mindreframer]

here is an example how the error message would look like:

ParamContractError:
       Contract violation for argument 1 of 1:
       Expected: (KeywordArgs[{:guid=>String, :occurred_at=>DateTime, :created_by_id=>Contracts::Builtin::Num}])
       Actual: {:guid=>"4fea1b56-3218-4c4c-a2ce-6db42d8e445f", :occurred_at=>"1", :test1=>1}
       Missing Contract: {:test1=>1}
       Invalid Args: [{:occurred_at=>"1", :contract=>DateTime}]
       Missing Args: {:created_by_id=>Contracts::Builtin::Num}
       Value guarded in: Events::AbstractEvent::initialize
       With Contract: KeywordArgs => NilClass

[egonSchiele]

Hey all, Sorry for my late response here. @mindreframer could you update the data hash? I like that better than running the contracts twice.

[mindreframer]

Hey @egonSchiele, good to hear from you!

Because the discussion here ended kinda abruptly and I liked the idea of contracts for Ruby, I have continued my work on a fork here: https://github.com/ddd-ruby/contracts.ruby

Many changes I have introduced would be too disruptive and would be probably rejected here after a longer discussion, and honestly, I would not even blame you for that :). You as maintainer of this project should be more conservative towards changes.

I tried to simplify contracts from the DX perspective, that means

• less backwards-compatibility (drop support for rubies 1.8.7- 1.9.3)
• faster tests: remove cucumber tests, because they are kinda fragile and expensive to maintain
• increase the code climate index (now at 3.9), that required quite some refactoring
• reduce cyclomatic complexity as much as possible, that means all the nested if-else blocks were refactored to be much flatter

Overall the resulting codebase should be simpler and a bit easier to maintain / contribute to. One gotcha: the refactoring made it a bit slower, it is roughly 10% slower in trivial benchmarks that the original implementation.

My current fork satisfies my needs and I have already invested enough efforts into it. If you are interested in some of those changes, you might consider merging some parts yourself...

I really hope this does not appear offensive or rude to you. I just did not have the patience to wait for an undefinite time period for a decision from your side. My brain just does not work like this. :P

Overall thanks for Contracts and maybe you will like some parts of my changes and use them.

Best, Roman

[egonSchiele]

No problem Roman, it is not offensive at all :) I don't work in Ruby these days, so it is a bit of overhead for me to maintain the project, which is why my response took a while. I'm really glad to see you like the project ... you have made a ton of commits!

I wish I had more time to work on contracts, I would definitely look at your changes. The codebase is quite complex so I would like to simplify it also.

[mindreframer]

@egonSchiele thx for staying cool! If you don't work in Ruby anymore, maybe you could look around for another maintainer / co-maintainer with rights to merge / push to Rubygems? That way contracts would not suffer a slow death...

A separate Github team would be a nice touch, like: https://github.com/contracts.ruby/contracts Then you could post a "looking for maintainer(s) for contracts" post on http://www.rubyflow.com/ and link to a github issue with the same title... Some people with more time than you and active Ruby investment might be interested. Pick somebody you would trust to keep the project alive.

Also there are 23 watchers on the repo. )))

But well... That is maybe something you should figure out for yourself :)))

Best, Roman

[mindreframer]

here is another project where the original maintainer looked for new maintainers:

https://github.com/fgrehm/vagrant-cachier/issues/143#issuecomment-273523976

[egonSchiele]

good idea!