I mostly agree, with some of the additions of course being more
important than others.

On Sun, 2006-12-31 at 02:27 +0900, Trans wrote:
> * <code>object_class</code> instead of </code>class</code>. I get sick
> just looking at <code>self.class.foo</code>. And it prevents use of
> "class" for other variables/methods. (Hence the all too frequent use of
> "klass"). <code>object_class</code> on the other hand is nicely
> analogous to <code>object_id</code>.

I completely agree here.

> * Allow a comma between the two <code>alias</code> arguments --getting
> an error on that is really annoying. Actually why is <code>alias</code>
> a keyword? Why have both <code>#alias_method</code> and
> <code>alias</code>? I have always been told that keywords were to be
> avoided.

I would personally prefer that the `alias' keyword be removed, but I
have noticed how at least one prominent Rubyist, which has my utter
respect, tends to use it all the time. Nonetheless, be gone with it!

> * 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.
> But at some point the trick has to be performed.

+1

> * Another hassle when metaprogramming. <code>#send</code> should work
> for public methods only! There's a big issue with backward
> compatibility here. I have the solution: <code>#object_send</code>.
> It's a better name anyway b/c it stays out of the way (eg. my Email
> module would like to have a #send method, you dig?). And #send itself
> could be deprecated slowly. BTW <code>#funcall</code> for the alternate
> private-accessing send is a <b>terrible</b> name, try
> <code>#instance_send</code>. (And yes, I'm begging here!)

I agree that `funcall' is a weird name... "call a function". What
function? I thought we agreed on calling them methods!


Cheers,
Daniel