:if condition fails with "wrong number of arguments (1 for 0) (ArgumentError)" when lambda doesn't accept an argument

[trailblazer]

:if condition fails with "wrong number of arguments (1 for 0) (ArgumentError)" when lambda doesn't accept an argument

[apotonick]

Sorry, this issue didn't come through via email - I found it by accident! 😁

Yes, this is documented in CHANGES and I also blogged about it (uhm.... probably).

As you already guessed, the "problem" is uber, which now handles all the dynamic options (like if: lambda { .. }. This breaking change was deliberate. Apologies for the breakage, though, but I had to cleanse the options - now they're all executed with the same mechanism.

You can fix that by ignoring the args, as in

if: lambda { |*| beers? }

Your suggestion to check arity is clever, however I decided not to do that a while ago as it adds complexity and still doesn't catch all the gotchas.

Is the |*| OK for you?

[brentsnook]

My 5 cents - I'd allow blocks that have no parameters because I think that having to capture them when you don't need them just adds noise. I prefer handling that problem even if it adds complexity rather than let clients of uber/representative have to handle it. In that case I'd either handle the arity mismatch if possible or take the opportunity to fail in a more friendly way in order to make it easier for people to troubleshoot. It's also a breaking change (as we found out) - I'm not sure if you're following semantic versioning but I'd expect the major version to bump with a change like this.

These are just suggestions though, we've already worked around it as you suggested :)

[apotonick]

Hmm, yeah, a simple arity == 0 would actually do the trick. You're probably right, I might add it to uber.

I totally see your point on being "user-friendly" - however, this is a double-edged sword. Some projects completely went the wrong way in the last decade, providing "user-friendliness" to a degree where the internal magic, guessing and complexity outweighs the code use.

It's a pain in the ass to get rid of that madness now by deprecating all former forms. I don't want that in my gems and often explicit code is better understandable than magic methods that expose different APIs.

I try to but don't follow semantic versioning because I would be releasing a major version every two weeks. Most of my changes don't break existing code, though!

About semantic versioning: From my experience I can tell you that there should either be a fourth level (1.2.3.4), where 1.2 to 1.3 means internal (correction: semi-public) API has changed, or people should accept major number like 14.1.0. It is impossible to follow semantic versioning if your gem is going an aggressively innovative path.

[apotonick]

Here's the line from uber that executes the :if block: https://github.com/apotonick/uber/blob/master/lib/uber/options.rb#L77 It's so beautiful without any if..else 🌻 😏

[jan]

Also, you could update the readme, under available options and conditions. Adding |*| really isn't a problem, but finding out what needs to be done was for me.

[apotonick]

Thanks @jan - that's what pull requests are for 💋