in reply to Re^2: RFC: nicer subs with GetOptionsFromArray from Getopt::Long ( api design )
in thread RFC: nicer subs with GetOptionsFromArray from Getopt::Long
return value of the GetOptions call is a well established behaviour.
heh. Almost everything is a fail, sometimes even success. Even correct usage had bugs. Ive observed best use is ignore.
conciseness
its a virtue of mobile device :) virtual keyboards are a pain , esp with thumbs
I never understood how English people set the position of arguments: I'm Latin!
cpan is first come first serve. And hierarchy goes left to right. Sub:: is wrong prefix .
Getopt::Long::Sub sounds better?
Yes but all it says its based on getopt which we from the hierarchy already :) Vanity name Getopt::Long::Discipulus?
Sub::Long::Arguments or what?
Why 3 branches? Want 3 words why not Sub::GetoptLong ? Choices are hard even with guidelines Re^2: Naming a module that handles SIP2 (library protocol stopwords) Re: RFC: Automatic logger module.
...Which use cases are you imagining?
one where longargs is nicer or not identical to GetOptionsFromArray , but i struggle
|
|---|