On 15 Nov 2009, at 13:30, Marnen Laibow-Koser wrote:
> David A. Black wrote:
>>
>> I've heard people say that, while that's true, it's undisciplined to
>> actually use any of these techniques. I disagree radically. Of  
>> course,
>> I don't spend all that much of my time as a Ruby programmer writing
>> singleton methods -- but I do regard the individual object as the
>> center of gravity, and I regard classes largely as a convenience- 
>> macro
>> for creating objects bundled with certain behaviors at their birth
>> that may or may not represent what they do during their lifetimes.
>
> In other words, you're advocating writing Ruby rather like JavaScript.
> That makes some sense -- although, as a devil's advocate, I could ask
> why, in that case, Matz didn't design the language with a prototype
> model. :)

RubyQuiz #214 involved implementing Ruby for prototype inheritance. Of  
the four solutions provided the longest is Matthias Reitinger's which  
is just 33 lines of code, so prototype inheritance is hardly a complex  
addition to the language :)

I think the main point from this whole discussion is that Ruby is an  
object-oriented language, not a class-oriented or a type-oriented one.  
Duck typing can feel a little transgressive at first because we've  
been brainwashed for decades that programming is all about  
categorisation and type-safety, a mathematical endeavour. But nearly  
all real-world problems display a messiness and inexactitude which  
either make the use of type as the core criterion of design fragile  
and/or overly verbose: fragile because it isn't always obvious where  
the boundaries of a given type are drawn, and verbose because an  
apparently simple composite type may involve the definition of many  
hundreds of more specialised types and the coordination of their  
interactions.

Duck typing works well for the very same reason that when I read a  
book and it has a sentence such as "John kicks the ball" the only  
information I need about John is whether or not he can kick, and the  
only information I need about the ball is how it responds to being  
kicked. Now there's still a lot of information contained in this  
scenario but the laziness of the evaluation means that most of the  
supposed value that type can bring to bear on the problem can be  
achieved with much less effort.

Or put another way, mathematics is rarely a good user interface for  
design even though it's an excellent one for analysis and decomposition.


Ellie

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