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

On 30 May 2008, at 14:23, Mark Wilden wrote:
> On May 29, 2008, at 1:49 AM, F. Senault wrote:
>> Le 29 mai à 06:45, Eleanor McHugh a écrit :
>>>
>>> Numeric may well mean "numeric" in some particular sense, but that  
>>> is
>>> only a subset of all objects which may have a valid numeric
>>> representation. As I said, you're applying a static typing mindset  
>>> to
>>> a place where it's not necessary and whilst Ruby will let you do  
>>> that,
>>> in the long term you'll find yourself doing much more work with very
>>> little (if any) gain in software robustness.
>
> Man, I'm really not giving these replies the attention they deserve,  
> but I did want to mention one thing:
>
> This has nothing to do with "static typing." "Static typing" refers  
> to type checking being performed at compile-time instead of runtime.  
> It has nothing to do with interrogating an object's class during the  
> execution of a program. If you think about it, the class of an  
> object is _continually_ being interrogated at runtime, in order to  
> dispatch a given message to the right method.


That's why I said it was a static typing _mindset_ - because it's  
impossible to do static typing in Ruby. However putting this kind of  
type-checking boilerplate into code is attempting to do the same  
thing: allow only objects of a very limited type to be used in a given  
context. This isn't pushing against the Ruby Way because we're putting  
philosophy ahead of good design, but because the very shape of the  
language makes it ugly and cumbersome to do so.

I'm often minded of the following extract from Lewis Carroll when  
discussing this topic:

<quote>
'When I use a word,' Humpty Dumpty said, in a rather scornful tone,'  
it means just what I choose it to mean, neither more nor less.'
'The question is,' said Alice, 'whether you can make words mean so  
many different things.'

'The question is,' said Humpty Dumpty, 'which is to be master - that's  
all.'

Alice was too much puzzled to say anything; so after a minute Humpty  
Dumpty began again. 'They've a temper, some of them - particularly  
verbs: they're the proudest - adjectives you can do anything with, but  
not verbs - however, I can manage the whole lot of them!  
Impenetrability! That's what I say!'

'Would you tell me, please,' said Alice, 'what that means?'

'Now you talk like a reasonable child,' said Humpty Dumpty, looking  
very much pleased. 'I meant by "impenetrability" that we've had enough  
of that subject, and it would be just as well if you'd mention what  
you mean to do next, as I suppose you don't mean to stop here all the  
rest of your life.'

'That's a great deal to make one word mean,' Alice said in a  
thoughtful tone.

'When I make a word do a lot of work like that,' said Humpty Dumpty,  
'I always pay it extra.'

</quote>



In Ruby methods have a terrible temper and will soon tell you if  
you're misapplying them, so instead of trying to restrict the  
allowable types they can work on it makes much more sense to handle  
their temper tantrums when they occasionally throw them. The only  
reason I see any justification for not doing that in the original  
poster's code is because the method was talking to a remote web  
service and that could add an appreciable delay into finding out  
whether or not an error had occurred, but to be honest I'm not sure  
that in practice I'd be that concerned about it: instead I'd focus my  
energies on finding places in the application where the context could  
become muddled and redesigning so that they didn't occur in the first  
place.



Ellie

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