I was a bit surprised about Matz mention of the little things in his last ketynote. Little things can make all the difference! In fact, long time Rubyists have been waiting too long for some important "little" things. (IMO) Among them...
* Binding.of_caller. Yes, it's easy to abuse, and should be avoided at nearly all costs. But there are few pennies worth when nothing else will do. Some very cool metatricks are made possible by being able to access the caller's binding --the breakpoint lib being the most well known.
* object_class instead of class. I get sick just looking at self.class.foo. And it prevents use of "class" for other variables/methods. (Hence the all too frequent use of "klass"). object_class on the other hand is nicely analogous to object_id.
* Allow a comma between the two alias arguments --getting an error on that is really annoying. Actually why is alias a keyword? Why have both #alias_method and alias? I have always been told that keywords were to be avoided.
* String#resc as an inversion of Regexp.escape(string) and String#to_re as an inversion of Regexp.new(string).
* I'm dying here from remove_method hacks without #instance_exec. 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?
* A block can't take a block, nor default arguments. What kind of define_method is this? I realize this a trickier issue. But at some point the trick has to be performed.
* 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:
a = 1 dosomething do! |x| p a #=> error end
* Another hassle when metaprogramming. #send should work for public methods only! There's a big issue with backward compatibility here. I have the solution: #object_send. 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 #funcall for the alternate private-accessing send is a terrible name, try #instance_send. (And yes, I'm begging here!)
* This one's more of my own pet-peeve but nontheless, who wouldn't want a nice word alias for Class#===. In most cases I prefer to read what I'm doing rather then recall the interpretation of a symbol. There are of course some symbols that are rather obvious, either by indication of their form (eg. <<) or by their widespread use (eg. =), but Class#=== is not one of them. I would much prefer to see:
MyClass.instance?(myobject)
But I'm not picky about what word to use as long as it's readable.
* Oh, and lets not forget the forever arguable method name for (class << self; self; end).
No doubt there are a few others little things left unmentioned, and obviously some of these are much more important than others. But in any case, it's clearly striking that after hearing for so long about these generally well-accepted "little things", that Ruby has yet to take them in. I have a 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 he 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. So Ruby is being held back by a version number policy!!! That's pretty sad. And either matz just needs to get on with it (hey look forward to 3.0!) or accept some new versioning constraints.
Previous Topic
