On Sat, Jul 14, 2007 at 09:16:35PM +0900, Robert D. wrote:
Actually no, well your post is relevant and technical interesting but
I feel that Chad’s approach is quite elegant.
Maybe his motivation is wrong, I do not want to make a statement about
it, but I feel that his code is cleaner, more functional oriented,
more modern in some way…
What you have said will be worth gold when we have to optimize the
code but maybe it is premature optimization right now.
I wasn’t even aware that “foo = gets; foo.chomp!” would be more
than “foo = gets.chomp” – that’s news to me, and I’m not sure I get why
that should be the case at the moment. Even so, I tend to agree –
except in very limited circumstances, I think choosing the former over
the latter because of efficiency is a case of premature optimization.
Just some thoughts, after all both solution seem very reasonable to me
True. In the very limited case of these examples, we’re kinda making a
mountain out of a molehill.
Apart from that, every Array append operation is an inplace
modification. Changing an object’s state is at the core of OO
programming - so avoiding it is not realistic.
Hmm not sure it might not be possible to strive for some common goals
of pure functional and OO, but not an expert at all, just a thinker
It’s also worth noting that I never said we should never under any
circumstances do in-place modifications.
If you follow your thought consequently to the end you should switch
to a pure functional language because that is free of side effects.
Voil?, but I do not like too strict categorization.
I wasn’t aiming in that direction, anyway. Somehow, I don’t think
preferring “foo = gets.chomp” over “foo = gets; foo.chomp!” makes me a
candidate for never ever using Ruby again because “everything must be
functional”. I’m not sure why such a “love it or leave it” approach to
equating OOP with in-place modification whenever possible was brought up
in the first place.