Hey matz,

thanks for taking the time to respond to these.

> I'd like to see them as separated RCRs, even though the new RCR site
> have not seen its successful start-up yet.

If the RCR process gets fixed I would be happy to do some of them.
Right now only two people have submitted RCRs (last I checked) and the
communication on those RCRs is either broken or simply not being used
--I made attempts at emailing on the second --and I sumbitted the first
;-)

> The biggest reason we don't have caller binding API is the difficulty
> of the implementation under the current interpreter.  ko1 once said it
> is possible for YARV, so all we need is to design good API.  I don't
> think of_caller is the best name for it.

Really? By simply passing a block I can pass the binding of the caller.
I suppose passing a hidden block is too heavy though?

> By the way, YARV was committed in the Subversion trunk yesterday.

w00t!

> Could you describe what this change give you?  Removing class method
> does not allow local variables to be named 'class'.  Besides that I
> don't like the name "object_class", which is too vague for me.  class
> of an object?  a class object?  an object which is a class?  whatever.
> Maybe because I see many combination of "something id" but not
> "something class", besides "business class" etc.

The main thing is that it creates an exception b/c we are forced to use
a reciever, eg. self.class, so it can't be called as a "function" nor
made private. No other method is like that. Also I don't see why we
can't use it as a local var. Isn't the conflict with class<<obj
notation? Probably the parser should see /class\s+<</ as a whole unit,
which I think would allow for the var. But if you ask me the whole
"class << obj" notaton is yuk anyway. It visually clashes with Array#<<
and I'd much prefer someting like 'obj.meta_eval' -or-
'obj.singleton_eval'.

> |* 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.
>
> Are you proposing comma between alias arguments, or removal of the
> alias keyword?

Well, both. First and foremost however is the option of a comma. What
good reson is there for getting getting a sytax error here?

As for makeing alias a real method, that seems like a good idea. it
would allow us to use 'alias' as a var too.

If it possible to get rid of an exception and have things still work
fine, then it's a good thing, isn't it?

> |* <code>String#resc</code> as an inversion of
> |<code>Regexp.escape(string)</code> and <code>String#to_re</code> as an
> |inversion of <code>Regexp.new(string)</code>.
>
> Why?

It's much more concise. Take a simple example:

  re = /^#{user_input}/

We need to escape it:

  re = /^#{Regexp.escape(user_input)}/

vs.

  re = /^#{user_input.resc}/

The to_re, just goes hand in hand with resc, since they both regular
expresions --maybe resc should be to_resc, but tersness is especially
useful with it so I suggest resc instead.

> |* I'm dying here from remove_method hacks without
> |<code>#instance_exec</code>. This has to rank in the top three "little
> |things" that have been talked about forever, and it isn't that hard to
> |implement. So what's holding it up?
>
> We have it in 1.9.

Yea! But why not a 1.8 serious. It's an additon it won't break
anything. Correct me if I'm wrong, but I fear we won't see anything
from 1.9 in production for almost 2 years.

> |* Close the closures. Writing DSLs is great, but have you noticed they
> |all share the same closure? Have a way to reset the closure with some
> |sort of special block notation would shore-up this danger hole. Maybe:
> |
> |<pre>
> |  a = 1
> |  dosomething do! |x|
> |    p a  #=> error
> |  end
> |</pre>
>
> I am not sure what you meant here.  Could you elaborate (maybe in a
> separate post)?  Does any other language address this issue?

Okay. I will post separately.

> We have send, funcall, __send, __send! in 1.9.  Do we need more?

So we have the functionality. But can you tell me with a straight face
those are great method names?

Peronally, I really think you should get rid of __shadow methods
wherever you can. All it indicates is that the original method's name
is too common, so is likely to be overridden. And that's the reason I
suggest #object_send. All methods starting with object_ or instance_
are special. They are meta-programming methods and as such need to
stand aside in some fashion to avoid being overridden easily. This
consistancy is the beauty of it.

> In short, you are asking for the alias for Module#===, right?
> I don't see any good reason for it, where we can call
>
>   myobject.instance_of?(MyClass)
>
> but the good name for it would help accepting the proposal.

Yes. that's right. But I learned that it is better to ask the class if
you want to know the "truth". Sometimes the object might need to lie
--eg. as a proxy. I guess the most obvious name is:

  MyClass.class_of?(myobject)

> |* Oh, and lets not forget the forever arguable method name for (class
> |<< self; self; end). But please give us something concise.
>
> Yes, the name is the biggest obstacle now.

  #supercalifragilisticexpialidocius

Almost anything is better than nothing at this point.... okay maybe not
THAT, but you get my point.

> |No doubt there other little things left unmentioned, and obviously some
> |are more important than others. But in any case, it's clearly striking
> |that after hearing for so long about many such well-accepted "little
> |things", that Ruby has yet to take them in. I have a silly theory about
> |this actually --as odd as it may seem. The 1.9 version is the last on
> |the chain before 2.0 b/c matz is against using double-digit minor
> |numbers, eg 1.10. So we're is stuck with 1.9 as his test bed for 2.0.
> |Since 1.8 can only increment by teeny, these "little things", being not
> |little enough, can't make it in. Hence Ruby is being held back by a
> |version number policy!!! I think Matz just needs to get on with it (hey
> |look forward to 3.0!) or just lossen the version policy constraints.
>
> Digits that we have many (hey, we could have 9 more major releases!)

Good! :-)

> are not the reason.  Expected screams from all over the world suspends
> incompatibility and behavior changing for 1.8.

Yet most of these have no backward compatability issues --I guess
that's really my main point with "Little things"

Thanks and happy new year,
T.