Austin Ziegler wrote:
> On 28/12/05, Ian Bicking <ianb / colorstudy.com> wrote:
> > Also, to generalize, it seems that the Ruby community is perhaps less
> > sensitive to code smells or more tollerant of magic compared to the
> > Python community, which I guess was my larger point.
>
> Is it less sensitive to code smells, or is it something that isn't
> considered a code smell in Ruby? I think that the Ruby community is as
> .. rough on code smell as any community, but we consider different
> things smelly than the Python community does.

It's a little of both -- clearly there's some awareness among Ruby
programmers that opening classes introduces some possible issues.  And
the "sharp tools" comments imply that there's potential to cut
yourself, but people feel that's okay.  There's always a danger to any
technique; the question is how much danger is okay, depending on how
complex the problem at hand is.  I get a sense that prevailing opinion
in the Ruby community accepts a balance with more danger than in
Python.  Neither language forces you to be careful or not; in both you
could do explicit (runtime) type checking, or you can generate source
willy-nilly, or anything in-between.

Also, there's the issue about what is smelly at all.  Of course,
anything that is unusual is a bit smelly, so there's a circular
justification; opening a class is smelly in Python because people don't
do it, and people don't do it because it is smelly.  But just because
idioms are different doesn't mean that there isn't *any* commonality --
in both languages you are signficantly affecting code that isn't
"yours".

> I think that's where some of the resistance to your points come in; to
> the community at large, it is not necessarily considered bad to write
> something that essentially opens classes (or objects) again. See my
> own Transaction::Simple for an example -- it injects its functionality
> into any class that requests it. In Ruby, that's definitely not code
> smell. In Python? I don't know.

In Python, probably with a delegate, though multiple inheritance or a
mix-in would also be possible.  Also, I think there's something very
different about a class that pulls in functionality, from code that
pushes functionality into a class that might not be expecting it.  As I
said, there's room for discussion -- there's probably very useful rules
of thumb that could be offered about what's a good use of this sort of
feature, and what's bad.  

  Ian