Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

When is a feature bloat?

by ajt (Prior)
on Mar 18, 2003 at 09:39 UTC ( #243922=perlmeditation: print w/replies, xml ) Need Help??

Dear Monks,

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 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.


Replies are listed 'Best First'.
Re: When is a feature bloat?
by hv (Parson) on Mar 18, 2003 at 10:54 UTC

    One aspect worth considering is how the coder would work around lack of the convenience function, and how irritated she is likely to be about needing to. If, for example, you have a file_parse but not a filehandle_parse, that's likely to be very irritating when you have a filehandle but don't know the filename; when it's the other way round it isn't too bad, since you can just open the file to get the filehandle.

    Similarly, if you have a string rather than a filehandle it may not be too difficult to work around (open(my $fh, "<", \$string) is newly available in 5.8.0), but if the code is only going to do:

    sub filehandle_parse { my $fh = shift; my $string = do { local $/; <$fh> }; ... work on $string }
    then it may seem like an unreasonable inefficiency, particularly since the string_parse functionality could be exposed directly (as below) for almost no extra cost.

    It can also be worth putting in some placeholders for future optimisation: if string_parse is your primary entry point, but you anticipate that some users of the module may need to parse large files, putting in a

    sub filehandle_parse { my $fh = shift; string_parse(do { local $/; <$fh> }); }
    leaves room to implement that in a more memory-gentle manner in the future, without your users needing to change their code. Of course the functionality itself determines how likely that is ever to be useful.

    No hard and fast rules, though; the main danger is that the "surface" of your module may become too complex. I'm a great believer in polymorphic methods to reduce that complexity ("EXPR may be a filehandle or a string"), but that approach isn't for everyone.

Re: When is a feature bloat?
by Corion (Pope) on Mar 18, 2003 at 10:12 UTC

    I find convenience methods necessary - I don't want to slurp a file into a scalar, I want to pass a filename (or a file glob or an URI, or a callback, if applicable) to the function. This boils down to either massive dwimmery within the core function or some (several) wrapper functions, for example for the parse_file/parse_uri part versus the parse_scalar part.

    If you fear that those helper functions bloat your original module, create a *::Simple or *::Common module, which encapsulates the more common cases (for example, HTML::LinkExtor, HTTP::Request::Common or Regex::Common are such modules). A *::Simple module would cut down on the options and supply sensible defaults.

    perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
•Re: When is a feature bloat?
by merlyn (Sage) on Mar 18, 2003 at 12:58 UTC
Re: When is a feature bloat?
by Anonymous Monk on Mar 18, 2003 at 10:50 UTC

    Totally off-topic, but I'm curious - what's with the style of "brian d foy?" I found this style guide which creates a lot more questions than answers (such as WHY?). He also has press mentions all of which is giving me a really surreal haven't slept in 72 hours type feeling. Anyone know why he insists on that notation of his name?

      From what I remember (I think it was in a TPJ issue) - perl is case sensitive and so is brian.


        I can still name variables with mixed case in Perl though.

      He's the artist formerly known as Brian D. Foy.

      And that, as far as I can tell, is the jist of the whole thing.


      Maybe he is an ee cummings fan :)

      Life is a tale told by an idiot -- full of sound and fury, signifying nothing. William Shakespeare, Macbeth

Re: When is a feature bloat?
by dws (Chancellor) on Mar 18, 2003 at 20:27 UTC
    When is an added feature bloat, and when is it actually useful?

    Bloat is subjective: If there's a lot of stuff in an API that I don't have any use for, it's bloat. The stuff I use isn't bloat.

    The problem comes when an API (or a program) starts serving diverse communities, with non- (or barely-) overlapping needs and desires. Each might have a valid reason for a set of convenience methods, but, taken as a whole, everyone cries bloat. Microsoft Word is a good example of how this happens. The Word Product Managers will tell you that for every feature, there was someone who asked for it.

    The only no-brainer bloat is stuff that nobody uses.

Re: When is a feature bloat?
by BrowserUk (Pope) on Mar 18, 2003 at 21:53 UTC

    To my mind, a feature becomes bloat when I can achieve the feature in my own code, using less code than it adds to the module.

    Perl itself doesn't have a log10 function, as this can easily be simulated by the programmer using the provided log2 function.

    Personally, there are quite a few CPAN modules that have features I would use, if I didn't have to take all the 'value-add' functionality as well. I think that providing generic functionality in many modules detracts from them rather than adding to them.

    Example. There appear to be at least 3 different modules that will perform url-encoding and decoding.

    Wouldn't it make more sense to have a single, lightweight module to do this and have the other 3 modules require it?

    Where a module provides a collection of features that are unlikely to all be used in every program that uses the module, the POSIX' modules way of only loading those subs that are asked for is much prefereable to the method used in some others where the code is loaded regardless, but only those subs asked for are exposed. This seems to be the worst of all worlds as it means that I am loading code that there is simply no way for my program to use anyway, which seems more than a little pointless.

    Examine what is said, not who speaks.
    1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
    2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
    3) Any sufficiently advanced technology is indistinguishable from magic.
    Arthur C. Clarke.
Re: When is a feature bloat?
by Elian (Parson) on Mar 18, 2003 at 19:26 UTC
    A feature is bloat, as far as I can tell, whenever it does something someone doesn't immediately need, or understand. Or they could do themselves and thus don't see the reason for a module to do it. Or when it does something different than the way they've been doing it for the past decade and since it's been good enough then why would you want to change it?

    Not, mind, that I'm being cynical or grumpy at the moment.

Re: When is a feature bloat?
by oakbox (Chaplain) on Mar 22, 2003 at 10:59 UTC
    Have a goal in mind and stick with it. When your module starts performing functions outside that goal, it is bloating.
    Any function that is not inline with the goal of the module, but would be a nice addition belongs in a second module that inherits from the first.
    A good example of this is GD. GD's goal is to provide an interface to a few primitives of image manipulation. That's ALL IT DOES. Graphing, 3D graphing, image resizing, etc etc etc, are all out in different modules.
    That's my yardstick, anyway.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://243922]
Front-paged by IlyaM
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2018-03-22 10:20 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (273 votes). Check out past polls.