I was a bit surprised about Matz mention of the little things in his
Little things can make all the difference! In fact, long time Rubyists
have been waiting a long for some important “little” things. Here’s
some of the things on my little list…
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
object_classinstead 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
object_classon the other hand is nicely
Allow a comma between the two
an error on that is really annoying. Actually why is
a keyword? Why have both
alias? I have always been told that keywords were to be
String#rescas an inversion of
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_methodis 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.
for public methods only! There’s a big issue with backward
compatibility here. I have the solution:
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
#funcallfor 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:
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). But please give us something concise.
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.
PS. [And, yes, I took my own advice. I removed this from my blog --“it
is better to share than to own”.]