Re: The duck's backside

On Wednesday 28 May 2008 17:23:30 Mark Wilden wrote:
> On May 28, 2008, at 1:44 PM, David Masover wrote:
> 
> > Put it this way: What's the point of using, say, Erlang, if you  
> > never use its
> > concurrency features?
> 
> All I can do is repeat what I said: the ONLY point to ANYthing (in  
> programming) is as a means to accomplish some purpose. If using Erlang  
> accomplishes a given purpose best, then it should be used, no matter  
> what its concurrency capabilities. One reason might simply be that a  
> given programmer is more comfortable in that language than another,  
> and can therefore accomplish the task faster.

Even if the problem doesn't require concurrency, the main reason for choosing 
Erlang in the first place is its threading model. If you don't like Erlang's 
threading, chances are, the rest of it is done better in other languages.

I'm not saying that we don't want you if you won't do Ruby duck typing. Just 
saying that I consider duck typing to be a major draw to Ruby in the first 
place.

I kind of feel like you're doing the equivalent of this:

i = 0
while(i < some_array.length)
  do_something_with(some_array[i])
  i += 1
end

Yes, Ruby can do that, but I think most of us agree that a major appeal of 
Ruby is being able to do this instead:

some_array.each { |item|
  do_something_with item
}

> > No, it says "v is of class Numeric." It's very explicit, and makes the
> > assumption that anything which acts like a number will eventually  
> > inherit
> > from Numeric.
> 
> Well, the desired goal is in fact to recognize objects that are  
> numeric. One of the purposes of classes in OOP is to categorize things.

Given single inheritance, you're not going to force everything into the exact 
category it belongs. I know I implemented a class to represent DNS serial 
numbers and their associated math. It didn't inherit from Numeric, but it did 
have to_i.

Maybe that was bad design on my part, but the point of duck typing is that we 
don't need to care if it calls itself "Numeric". Instead, we care that it 
acts like a Numeric -- it responds_to +, -, and probably to_i and integer?

You've probably heard all this before, of course.

> > Remember the above -- I could actually completely redefine Array, or  
> > Numeric,
> > etc. So even your assumption that "Numeric === foo" tests for  
> > Numeric is
> > really only based on convention -- you're assuming that no one,  
> > anywhere in
> > your code, is doing stuff like this:
> >
> > Numeric = nil
> 
> That's not merely being unconventional--that's insanity. :) Anyway, it  
> applies even more so to methods, which aren't in the global namespace.

Alright, without altering the global namespace, and with very possibly a good 
excuse, I could do something like this:

class IpAddress < Integer
  def to_s
    # return '12.34.56.78'
  end
end

Now, that actually won't work without a bit of massaging -- the numeric 
classes don't have constructors. And there's already a built in IP address 
class, so this would be pointless.

But I'm not sure there's any more reason to believe that something which is a 
Numeric (or claims to be) is going to give you the semantics you want, than 
to believe the same of something which supports to_i (or to_int, which is 
probably more correct).

> >> (think Cowboy#draw and Artist#draw).
> >
> > Yes, that is a downside of duck typing, as currently implemented,  
> > but doesn't
> > really apply to :to_i.
> >
> > Also, context matters. If Cowboy and Artist are both in a GUI widget  
> > library,
> > that Cowboy is asking for trouble.
> 
> That's true, but it wasn't my point. The question is whether all  
> methods with the same name in all active classes should be  
> semantically equivalent. I think that's a rather larger assumption  
> than that Numeric means "numeric."

The assumption you're making with Numeric isn't that Numeric means "numeric", 
but that all possibly numeric values are contained in Numeric.

I think your use case had something to do with a fragile web service, so this 
actually could make a lot of sense to you -- it might even be worth checking 
if it's an Integer.

But in the general case, I like that much of my code is actually abstract 
enough to swap something of an entirely different type (or class) in and have 
it do something useful. Recently, I actually wrote an entire class for 
storing things (a two-dimensional map) without knowing what kind of object 
I'd be filling it with. I ended up filling it with Symbols.