Personally, I don't know whyhasOption 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 confusinghasOption() /hasArgument() methods still remain.

What if we deprecate those methods in 3.3 and add instead two pair of new methods:isOptionDefined / isOptionProvided andisArgumentDefined / 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 theInputInterface. That means we'll need another interface, but that won't help much, because existing methods typehint onInputInterface and this is unlikely to change.

However, I agree that deprecatingInputInterface::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 theInputDefinition.

Great 👍 For the naming, my preference would go for

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

(in this order).

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

Just for the record: I don't likeisOptionDefined() because to me the meaning is really what I expect for the currenthasOption 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 likeisOptionSpecified 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, whereasbin/console list --show-hidden would have been equivalent tobin/console list --show-hidden=true (andbin/console list --show-hidden=false to explicitly hide):

bin/console list --show-hidden# show hidden commandsbin/console list --show-hidden=true# show hidden commandsbin/console list --show-hidden=false# hide hidden commandsbin/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 theInputInterface::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 theInputDefinition from the input, deprecating these methods seems to create an unnecessary complex path to get the definition. You can get it throughCommand::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. :)