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.
