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

  • Comment on Re^3: RFC: nicer subs with GetOptionsFromArray from Getopt::Long ( api design )