From: Eleanor McHugh <eleanor@...>
Date: 2008-05-31T01:57:52+09:00
Subject: Re: The duck's backside

On 30 May 2008, at 14:18, Mark Wilden wrote:
> On May 29, 2008, at 3:37 AM, David A. Black wrote:
>> Duck typing, as a way of thinking, meshes nicely with Ruby, as a  
>> tool,
>> because of how Ruby objects are engineered: the *only* thing that you
>> can measure with certainty is what an object does when you send it a
>> message.
>
> No, you cannot possibly measure with certainty what an object does  
> when you send it a message. The only thing you can measure is  
> whether it will throw a runtime error because it doesn't implement a  
> method for the message.

There are many other kinds of runtime error than that, and it will be  
a highly unusual (and I suspect carefully designed) method which  
doesn't raise any of them when provided with garbage inputs. Hence why  
Duck Typing is the preferred approach in Ruby.

>> You can ask it what its class is, what its ancestors are,
>> what methods it responds to, and so forth... but in the end, you hit
>> the singularity: the sending of the message.
>
> However, an object's class and ancestors _determine_ what messages  
> an object responds to. That's what they're there for - to hold  
> message maps.

To some extent. But as an individual object's message maps are  
alterable at runtime, knowing its class and ancestors is a very  
incomplete picture of what that object is.

>> Hmmm. Is it that objects change their type, or is it that variables  
>> do?

Unless the definition of type is "a mutable correlation of behaviour  
and state, integrated over time" it's clear objects can and do change  
their type at runtime.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason