From: Devin Mullins <twifkak@...>
Date: 2006-12-31T05:52:32+09:00
Subject: Re: Little Things

I wonder if the reason a lot of these things don't happen is that matz 
doesn't really need them, and those that do, can't agree on a syntax (or 
elect a representative to make the decision for them). See below.

Trans wrote:
> * Binding.of_caller.
I'd really prefer something more flexible, like what Mauricio did, or 
what Evan is doing with Rubinius.

> * <code>object_class</code> instead of </code>class</code>.
Interesting thought, but two things:
- We could just fix it so you can say "class = ...". After all, local 
variable "foo" and method call "self.foo" can coexist.
- It breaks the Huffman principle (for that matter, so does the current 
notation) that Tanaka Akira cited at RubyConf '04. We use self.class a 
heck of a lot more than object_id -- why should its name be longer?

> * Allow a comma between the two <code>alias</code> arguments
I think the reason both alias and alias_method exist is because the 
latter's supposed to be limited to dynamic situations. Akin to def vs 
define_method, undef vs undef_method, etc. That said, I'm ambivalent.

> * A block can't take a block, nor default arguments. What kind of
> <code>define_method</code> is this? I realize this a trickier issue.
See 1.9.

> * Close the closures.
Interesting. Of course, the method author has the choice of calling 
instance_eval. And, well,

def do!(&blk)
   obj = Object.new
   obj.define_method(:my_little_pony, &blk)
   obj.method(:my_little_pony) #.to_proc, if you prefer
end

a = 1
dosomething &do! {|x|
   p a
}

> * Another hassle when metaprogramming. <code>#send</code> should work
> for public methods only!
See 1.9.

> * This one's more of my own pet-peeve but nontheless, who wouldn't want
> a nice word alias for Class#===.
I'd like a nice word alias for Object#===. With Class#===, I prefer 
using is_a? class.

Oh, and the spirit of Dave Thomas asks you to PDI.

Devin