Feature: Allow spinal case for console command line options

[giovdk21]

Console command line options now are defined in the options() method of the Controller and mapped to the corresponding properties.

We could have spinal case options mapped to camel case properties in the same way controller actions are handled.

So for example you would have --my-option=123 that will be stored in $this->myOption allowing for more command line friendly syntax.
In this scenario writing --myOption=123 should still work (also for backward compatibility) but when, for example, showing the help message, the values returned by the options() method should be used (if I'm right, it is already this way).

What do you think?

[qiangxue]

There's no technical problem. My only concern is if this will cause confusion. Which format should be used in options()?

[giovdk21]

In options I'd say the user define the format he wants to be shown in the help message. (./yiic help )

But then --my-option should just be an alias of --myOption (you can define this as a convention for Yii command line apps)

[samdark]

I'm not sure it's a good idea overall to define options differently than these are actually used.

[giovdk21]

It would be just a matter of mapping them since the common format of command line parameters is with the dash but it is not possible to name a class property in the same way.

But I was suggesting to have them as an alias for backward compatibility but we can ignore this if it makes it confusing.

[samdark]

I think it is confusing.

[giovdk21]

Ok, but what about having it in this way:

• in options() the user defines the name of the parameter he wants (camel case or spinal)
• if spinal it will be mapped to camel case but the final user won't be able to use the camel case one

In this way it does not break backward compatibility of the framework and it shouldn't be confusing.

Of course then if the user changes it, it will break the BC of his app, but then that is up to him.

[samdark]

I don't have strong opinion about this one. @qiangxue can you help with decision?

[qiangxue]

I think we should leave it as is. As said previously, the biggest concern is that this may cause confusion. Without documentation, this will become a hidden feature; but if documented, this will bring confusion.

[ghost]

Really old ticket, but what an awful decision to reject the idea and close it. There is not a single *nix command in existence that uses options with camel-cased names. :(