From: ara.t.howard@...
Date: 2007-02-18T03:42:00+09:00
Subject: Re: Oppinions on RCR for dup on immutable classes

On Sun, 18 Feb 2007, Stefan Rusterholz wrote:

> unknown wrote:
>> On Sun, 18 Feb 2007, Stefan Rusterholz wrote:
>>
>>> Care to explain why you chose defining a method with the sole purpose of
>>> raising an exception over removing the method instead?
>>
>> yes - for illustration  ;-)
>
> And in a real situation, why would you chose to do so? What would be the
> reasoning to justify that?

the one that springs to mind is

   module Mixin
     def average
       total.to_f / n.to_f
     end
     def total
       raise NotImplementedError
     end
     def n
       raise NotImplementedError
     end
   end

this give a much nicer error than NameError or something about nil not
responding to 'to_f'.

another is

   module DRbUndumped
     def _dump(dummy)  # :nodoc:
       raise TypeError, 'can\'t dump'
     end
   end

this is more useful than it looks.  what it means is that any object in a
hierarchy will cause a particular exception to get thrown, indicating that a
drb proxy should be used.  this is a good approach because you can mark objects
which are normally able to be marshaled as not being so in a way that's viral
to other objects holding references to this object.

>
>> this is a side effect of strong dynamic type systems
>
> I am well aware of that. I used ruby for over a year ;-)

sorry for being pendantic then.

> But you in this situations you have two options, define a method whichs
> only code is "raise Exception" or not define the method at all.
> Or in your example the choice is between redefining the method with one
> whichs only code is "raise Exception" or undefine the existing one.
> In both situations: why would you chose one over the other?
> I'm sorry if I'm obnoxious with that :)

that's ok.

cheers.

-a
-- 
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama