Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Short options as strings #12

Open
victor opened this issue Dec 8, 2014 · 3 comments
Open

Short options as strings #12

victor opened this issue Dec 8, 2014 · 3 comments

Comments

@victor
Copy link

victor commented Dec 8, 2014

I find that using chars for the short options, while technically correct, is a bit convoluted, specially since they are later converted to NSStrings anyway. I'd request to have additional methods in which short options are declared as NSStrings, as that would make them more usable from Swift (where getting hold of a single char is a pain)

@tomaz
Copy link
Owner

tomaz commented Dec 16, 2014

Agree. It makes it difficult to setup short option in Swift. On the other hand using char is nice in Objective-C. Need to come up with nice implementation for both, without introducing another set of registration methods. Also don't want to break existing implementation. Perhaps adding new registration method that would accept "registration object" which would describe all parameters would be nice and future proof (currently there could be two subclasses, one taking char, one string for example).

@victor
Copy link
Author

victor commented Dec 16, 2014

What about adding a convenience registration method that takes a string and picks the first char, calling the other method with it?
That would be easy to implement in ObjC, and convenient to use from Swift. You can implement it in a category only imported when needed, so as not to pollute the namespace.

El 16/12/2014, a les 11:33, tomaz [email protected] va escriure:

Agree. It makes it difficult to setup short option in Swift. On the other hand using char is nice in Objective-C. Need to come up with nice implementation for both, without introducing another set of registration methods. Also don't want to break existing implementation. Perhaps adding new registration method that would accept "registration object" which would describe all parameters would be nice and future proof (currently there could be two subclasses, one taking char, one string for example).


Reply to this email directly or view it on GitHub.

@tomaz
Copy link
Owner

tomaz commented Dec 16, 2014

That's exactly how I meant to implement it, but don't just want to add another method. Instead I'm aiming for more flexible and future proof approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants