I got a couplea interesting comments to my post on container classes in perl.
Both of them seemed to make the same arguments "In Large systems ... you are going to need it ... better to do it earlier than later."
Who every said I was designing a large system? And the rest of it just doesn't sound agile enough to me. No, you AIN'T Gonna Need it.
In other words, I think you don't need a container class until you actually need a container class. (Did I say,
you're NOT gonna need it yet?)
When behavior starts to creep into your data structure, you risk not Just Doing It Once, so you re-factor into a class. I'm just writing in opposition to premature OO-ification - the root of a couplea kinds of evil. :-)
You're NOT gonna need it
gav on 2003-09-08T19:09:57
I think you're blindly following a rule here. Sure you might not need it right now, but don't go and design yourself down a dead end. I like to have two lists of features; features we need right now, and features we are going to need soon. You don't want achive something in the first list at the expense of making something in the second very hard.
Doing the simplest thing possible in a lot of cases is to just return a hash of data. I've found that if you return a blessed hash with proper methods (using Class::Accessor of course) it makes things more managable and you'll appreciate it later on.
But it's so easy ...
autarch on 2003-09-08T21:58:00
Perl makes this sort of stuff so easy. Generating a quickie little class is trivial, given that there's lots of helper modules on CPAN for it, and you can roll your own with code generation (at runtime) in about 10-15 lines anyway!
So since it's so easy, why not just do it?
YAGNI
pdcawley on 2003-09-09T04:46:15
You're dead right at one level. My rule of thumb for this is that as soon as I start to manipulate an anonymous array or hash in more than one module then it's time to turn that anonymous structure into its own class. And if I find myself monkeying with it in three modules then that's a definite code smell.
namespaces
I'm not sure I'm qualified to respond to the words of someone with such a high
GPA, but here goes:
Though inheritance is usually needless complexity, and functional programming
with ADTs is the One True Way, using packages in Perl *is* still very
convenient. It lets you push the functions on your ADT into the namespace of
that package, instead of having one huge function namespace. So instead of
oparate_on_foo($foo) and operate_on_bar($bar), we can just say
$foo->operate() and $bar->operate(). This ends up making your code more
terse, making the logic more obvious.
Yes indeed.
james on 2003-09-09T08:58:20
Who every said I was designing a large system? This is true. However, I think I can clarify -- if your code needs to be maintained and there is a chance that it might need to be extended in the future, then a little work up front will pay off big time. By putting the behaviours in a class you can avoid action-at-a-distance that might apear later. And yes, 'You Ain't Gonna Need It' is a valid comment. But then again, XP isn't a dogma, its a good starting point.
When behavior starts to creep into your data structure, you risk not Just Doing It Once, so you re-factor into a class. I'm just writing in opposition to premature OO-ification - the root of a couplea kinds of evil. :-) Absolutely. This was the point I was trying to make before. If you need nothing but the behaviours of an Array or a Hash, thats fine, but if there is a need for other behaviour, then create a container. I have a rule of thumb that I often apply -- if I need to use a hash or an array outside of my immediate scope a flag goes up and I need to look to see if there are behaviours that can be refactored into a class.
When all is said and done, Perl's hash and array types are abstractions. In general it would be nice to treat them like any other abstraction, however, Perl doesn't provide them as first class objects, which is a pity.
Mwah hah hah ha!
pdcawley on 2003-09-09T10:10:56
Heritable::Types + autobless, you know it makes sense!
