Re: When is it better to NOT release a new module?

If it were a templating module, I would say no. This area is somewhat less flooded, so the barrier to entry shouldn't be as high. However, I would urge you to make it clear why someone would choose this module over the established standard, Params::Validate. I don't see much difference here beyond syntax, and frankly, your syntax is pretty bizarre by comparison to that module's simple data structure spec. Is it really faster than Params::ValidateXS?

Comment on Re: When is it better to NOT release a new module?

Replies are listed 'Best First'.
Re^2: When is it better to NOT release a new module? by Tanktalus (Canon) on Nov 02, 2005 at 18:15 UTC
Make it clear why someone would choose this module over other modules, yes. But, if you can, also try to make it clear why one would not choose this module - what limitations or other downsides does it have? For example, some people have a perverse fear of source filters (others have a very reasonable fear of source filters ;-}), so because you use this controversial feature, you should clarify that. For example, I'm not sure, but somehow I think you'll have problems inside an eval STR. Maybe not - but the better you document what you can and cannot do, the more realistic users' expectations will be. Even if it means that I need to avoid doing something so that your module works, that's still relevant information. (And if you plan on cleaning up that limitation in the future.)	[reply]
Re^2: When is it better to NOT release a new module? by snowhare (Friar) on Nov 02, 2005 at 19:02 UTC
Substantially faster. Read more... benchmark-arg-parsers.pl (4 kB) `Rate simple_parms 28329/s params_validate 48077/s cf_standard_args 73529/s sub_parms_bind_parms_function_req 157480/s sub_parms_bind_parms_function 172414/s one_step_args 224719/s standard_args 229885/s sub_parms_method 238095/s sub_parms_function 270270/s positional_args 952381/s null_method 1666667/s null_sub 1666667/s` [download]	[reply] [d/l] [select]