Devin Mullins wrote:
> 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.

Well, it be nice to know what matz thought.

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

You mean a frame stack?

> > * <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.

Can it be done? Although, you loose access to the class in that case.
I'd rather have both.

> - 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?

But at the same time promotes duck typing ;-)

> > * 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.

> See 1.9.

Sure I know. But that's like how many years away?

> > * 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.

However, it's safer to ask the class since the object can more readily
"lie".

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

That's almost funny :D

Anyone else have any other common little things to add?

T.