Devin Mullins
12/30/2006 8:53:00 PM
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