Bool options bug! about slop

[ddnexus]

Definitely a bug:

slop/lib/slop/option.rb

Line 98 in 4394168

@value || default_value

That means: if a boolean value is false it will return the default_value, which in this case is true, hence it is impossible to get the right (false) value!

Something like the following should fix the problem:

      @value.nil? ? default_value : @value

[ddnexus]

Is this project abandonware?

I switched to Optimist... single-file lib drop-in that doesn't need to be a gem dependency.

[leejarvis]

Thanks for the report.

Is this project abandonware?

No it is still maintained.

I switched to Optimist... single-file lib drop-in that doesn't need to be a gem dependency.

Great, I'm glad you found a solution.

[ddnexus]

Great, I'm glad you found a solution.

I needed to release pagy and I fricked out, but I like your project! 👍

[leejarvis]

@ddnexus What's the purpose you're forcibly changing the value in the Options? e.g. doing this: opts[:false] = true — this is unexpected behaviour IMO. Maybe Slop should raise an error when you try to reassign a value, but it's meant to be readonly. If you change the value explicitly then we no longer have tracking of the original value. The following all works as expected:

% ruby demo.rb
{:false=>false, :true=>true}
% ruby demo.rb --false
{:false=>true, :true=>true}
% ruby demo.rb --false --no-true
{:false=>true, :true=>false}

[ddnexus]

Well, an accessor method that doesn't return the actual instance variable value, but changes it on the fly because it "expects" it to be any arbitrary non-false value, is conceptually plain wrong IMO.

You could object that it's not an accessor, but a method that returns the content of an instance variable is hardly something else... even if it perform tricks on your back 😉.

Returning a default value on read instead of assigning it to the instance variable on creation is also not exactly following the principle of less surprise.... at least my own surprise 🫢.

But that's kinda personal.

Maybe Slop should raise an error when you try to reassign a value, but it's meant to be readonly

Why would you want to impose your own concept of "options" to your users? If I want to freeze the options I can just do it. If I want to use slop as a simple initializer/validator of some options, why would you want to stop me to edit the original options based on other conditional logic later in the script? Wouldn't that just reduce the flexibility of your tool for no advantage?

If you change the value explicitly then we no longer have tracking of the original value.

I definitely miss the point of "tracking" the original value.

My ideal options parser should just give me a simple hash of options after defaults and validations and leave the rest to me.

[leejarvis]

My ideal options parser should just give me a simple hash of options after defaults and validations and leave the rest to me

Sure. This is what to_h is for. opts is a Slop::Result and shouldn't be treated like a Hash, despite the existence of a #[] method.

[ddnexus]

So you should definitely raise an error if the user tries to change the Slop::Result, and put the opts.to_hash as a suggestion in the error message itself, in order to educate the user that indeed may think that opts IS a Hash or Hash-like thing.

Principle of less surprise! 😄

PS:

opts is a Slop::Result

That sounds weird as well to me (kinda "truth is not truth" 😄).

One would think opts is a opts hash... or maybe a Slop::Opts object which is likely a hash-like thing, since it even responds to [] and []=.

And why on Earth an object "meant to be read-only" has a []= AND even a defined attr_writer is beyond comprehension to me. 🤷

Maybe you can make it clearer starting from the README. Something like calling the variable like the object it represents or some funny variation like slopts or whatever but opts might be helpful.