From: David Masover <ninja@...>
Date: 2008-06-02T11:04:07+09:00
Subject: Re: The duck's backside

On Friday 30 May 2008 08:12:35 Mark Wilden wrote:

> If classes are not categories, what are they?

Classes are categories. But not all categories are classes.

> > Which ends up being more readable, among other things.
> 
> Exactly. It has absolutely nothing to do with Ruby's "mindset," or  
> "the way we do things in Ruby." We choose the latter because it's  
> better, not because it's the Ruby way. It's the other way around: it's  
> the Ruby way because it's better; not that it's better because it's  
> the Ruby way. The former attitude is pragmatic, the latter is religious.

There are fundamentally different ways to do it -- I'm guessing functional 
languages would do a recursive function. Lisp would iterate, but with... 
whatever the opposite of a callback is. (Long weekend, I'm slipping...)

We do it because we believe it's better. We call it "the way we do things" 
when a majority of us believe it's better. But obviously, not everyone agrees 
on what's better -- insisting that one particular way is better than every 
other way is also religious.

> There _is_ something wrong with it. It's harder to read and more prone  
> to error.

No, there's nothing wrong with it. Just because there's a better way doesn't 
mean the old way is wrong.

> > Can you outline a few real-world examples, where it's OK to get a  
> > descendant
> > of Numeric, but not something which merely implements to_i or to_f?
> 
> The obvious case is an object that implements to_i in a noncongruent  
> way. For example, let's say the number passed in is to be used as a  
> count. An IP address may respond to to_i, but it can't possibly be  
> correct in this context.

I think that's the disagreement. I prefer being optimistic about type 
checking -- assume everything's alright until something breaks a test. Others 
prefer being pessimistic -- assume a Numeric is a Numeric until you need to 
do something else.

Also: It depends on the context. It might well be that an IP address is fine.

> > Firstly, #class doesn't provide any way to be in multiple  
> > categories. Ruby
> > doesn't support multiple inheritance.
> 
> We're not talking about multiple categories - just one. In all my  
> years of using MI in C++, I've very rarely, if ever, seen a class that  
> didn't have a "dominant" base class. Most of the time MI is used for  
> mixing in. You might have a class, for example, that descends both  
> from Numeric and Observable, but obviously, its main category is  
> Numeric.

I'm not convinced that there's always a "dominant" base class. Simple example: 
IP addresses are both numeric (in a sense) and byte strings (and by extension 
arrays/enumerables), and their own thing. There might not be a class that 
supports all of these things, but the thing itself does.