|P is for Practical|
When is a feature bloat?by ajt (Prior)
|on Mar 18, 2003 at 09:39 UTC||Need Help??|
Some time ago I presented my first OO module Thoughts On Object-Oriented Module Design. Input Sought. for discussion. Since then it's been updated, upgraded and uploaded to CPAN XML::RSS::Tools. Because of it, I prompted brian d foy to take over and co-ordinated the repair of one of the module's core dependencies: XML::RSS. To me it's been a fine learning experience, and has resulted in the creation of one new module and the repair of an older one.
At the moment I'm working on yet another upgrade to my module, and my mind again turns to bloat. When is an added feature bloat, and when is it actually useful? As you may know there is a fine article over on Perl.com looking at the mess that is The Many Dates and Times of Perl, where many modules with uncoordinated APIs and suffering from feature bloat have created a module soup. There is a plan to rationalise things, so things will get better...
In the latest version of my module, I've added a lot more tests, extra documentation, and extra functions. The extra docs and tests add to the size of the distribution, but I think it's fair to say that they are a beneficial addition, and they don't slow the module down or increase it's memory foot print.
My problem lies with extra features. Do I emulate the API of other similar modules and provide multiple methods to do similar things? Do I really need a file_parse, string_parse, filehandle_parse and URI_prase? All make sense in the module, but are they just syntactic sugar that's making the module fat, or are they a clever way of making small scripts?
In my original post, I asked about bloat, and Ovid made some good comments, but I'm now throwing the question open to a wider audience, when is something useful and when is it bloat?
Update: Remove . as per merlyn's comment.