Personally, I don't know why hasOption would check the existence of the option. Why would you want to check this in the first place in user-land, what would be the benefit?

This solves part of the problem, but the always confusing hasOption() / hasArgument() methods still remain.

What if we deprecate those methods in 3.3 and add instead two pair of new methods: isOptionDefined / isOptionProvided and isArgumentDefined / isArgumentProvided ?

@javiereguiluz: Ideally, that's what I want to do. But we can only deprecate the method easily, not adding the two new ones to the InputInterface. That means we'll need another interface, but that won't help much, because existing methods typehint on InputInterface and this is unlikely to change.

However, I agree that deprecating InputInterface::hasOption/hasArgument() makes sense. As stated by @iltar, I don't see why the input should have such a method. It's not the input responsibility to check the option exists at all, but the InputDefinition.

Great 👍 For the naming, my preference would go for

• isOptionSpecified()
• isOptionDefined()
• isOptionSet() 

(in this order).

👍 For deprecating InputInterface::hasOption()/hasArgument(), the difference between the definition and the actual input should be explicit.

Just for the record: I don't like isOptionDefined() because to me the meaning is really what I expect for the current hasOption implementation to be, i.e: is this option defined at all in the definition ? (the same as defined options in the OptionResolver component). I do like isOptionSpecified better but not sure it's as explicit as given/provided. What do others think ?

Can you explain usage of this feature? To me, that's never needed. You shouldn't care about whether the user passed an argument or an option, you should only care about the value of such arguments and options. And the value is defined either by the default value configured in the command if not passed, or by the end user directly. But, and that's the important part, this shouldn't make a difference.

@fabpot in #20044 and #20432 we could have used this method.

#20044 this is a bug on Console that should be fixed, when passing --prefix="", the prefix should be empty.

@fabpot: I saw a use-case when working on the --show-hidden option of the #21075 (the commit was reverted as this option was rejected).
What I wanted was to show/hide the hidden commands automatically according to the format in case the option wasn't provided, whereas bin/console list --show-hidden would have been equivalent to bin/console list --show-hidden=true (and bin/console list --show-hidden=false to explicitly hide):

bin/console list --show-hidden       # show hidden commands
bin/console list --show-hidden=true  # show hidden commands
bin/console list --show-hidden=false # hide hidden commands
bin/console list                     # auto: show/hide hidden commands according to the format

Thus, the behavior is different according to the fact the option was passed or not... but re-thinking about it, that's probably bad semantics. I understand your point.

Still, do you think the InputInterface::hasOption/Argument() methods should be deprecated?
You may argue keeping it is harmless, but at least removing it would make the intention clearer: the input does not deal with the fact an option was passed or not.

On the contrary, let's close this :)

As there is no way to retrieve the InputDefinition from the input, deprecating these methods seems to create an unnecessary complex path to get the definition. You can get it through Command::getDefinition(), but you won't be able to do so elsewhere, for instance in a helper. These methods finally make sense to me...

Let's close this. :)