From: dblack@...
Date: 2007-01-08T21:43:19+09:00
Subject: Re: Little Things

Hi --

On Mon, 8 Jan 2007, Evan Weaver wrote:

>
> Regarding 'funcall', I would rather support a 'send'-derived word which
> reflects the message-passing nature of what is really going on. Also, my
> brain reads 'funcall' most intuitively as 'FUNCtion ALL'. However I
> think the tradition of ! modifying the receiver makes 'send!' for
> private methods not good. I don't have a better suggestion, though.

! doesn't mean modifying the receiver, though.  It means "dangerous".
It's used often for modifying receivers, but that's never been what
Matz says it means; that's just one form of danger.

> Regarding overriding 'send', I don't think that any method is too
> important to be overridden. Perhaps '__send' to always call the original
> version would be ok, but the idea of permanently disallowing some
> operation because it's "important" doesn't sit well with me. If I want
> to break Ruby, I want it to graciously break, instead of saying 'No'.
>
> Regarding the name of singleton classes, I think 'eigenclass' is ok. I
> am partial to 'shadow_class', because the singleton class shadows the
> real class. I would like to be allowed to instantiate new objects from
> them, as a sort of backhanded prototyping.

You can do something along these lines by cloning objects:

irb(main):003:0> a = Object.new
=> #<Object:0xb7f34c8c>
irb(main):004:0> def a.x; puts "hi"; end
=> nil
irb(main):005:0> b = a.clone
=> #<Object:0xb7f22ba4>
irb(main):006:0> b.x
hi


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)