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 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
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). 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.
T.
PS. [And, yes, I took my own advice. I removed this from my blog --“it
is better to share than to own”.]
“We need to Document Ruby (if Possible).” as part of the Design Game of
improving Ruby.
That kind of a statement is what could potentially kill the language.
We can have the best language on the Planet, but if the language
features are only accessible to those that are willing to go code-diving
for the answers, then the target audience is going to be slim.
The truth is that there are a lot of well intentioned programmers out
there, but they don’t have the first clue (or inclination) to go digging
deep into the bowels of Ruby (or any language).
That is why some of the less elegant languages have succeeded, and have
such a large following. It is (in large part) because of there
documentation. It is up-to-date, adequate, easy to search, and
well-defined.
I don’t pretend that all share my view on documentation, but for the
Ruby leader/CEO to put documentation so far down on the list I think is
going to make it difficult for language to grab ahold of programming
share the way that Perl, Python and PHP have.
Your welcome. I’m glad something good came from this post at least.
Sorry about the html btw, should have removed that.
for the answers, then the target audience is going to be slim.
I don’t pretend that all share my view on documentation, but for the
Ruby leader/CEO to put documentation so far down on the list I think is
going to make it difficult for language to grab ahold of programming
share the way that Perl, Python and PHP have.
Yea, I didn;t notice taht before. that is an odd statment to make. But
I wouldn’t put too much emphisis on it --sometimes people say things
without meaning all the conotations tha can go with them.
for the answers, then the target audience is going to be slim.
I don’t pretend that all share my view on documentation, but for the
Ruby leader/CEO to put documentation so far down on the list I think is
going to make it difficult for language to grab ahold of programming
share the way that Perl, Python and PHP have.
Yea, I didn;t notice taht before. that is an odd statment to make. But
I wouldn’t put too much emphisis on it --sometimes people say things
without meaning all the conotations tha can go with them.
Yes … I was there, and in fact a group formed to do just that –
document the syntax and semantics of Ruby 1.8. I know there’s a web
site, but I’ve forgotten where it is. Quite a few other “Ruby
improvement” projects started up at RubyConf 2006, and for the most part
they seem to be progressing nicely.
However, regarding “programming share”, or, as Eric Raymond says, “World
Domination”
(World Domination 201),
I don’t think programming share is as simple as having better
documentation than Perl, Python or PHP. Programming share comes from
“industrial support”, as demonstrated by Sun, IBM and Microsoft.
Perl and Python, and even PHP, to some extent, are very much “rebel
languages” alongside Java and C++. Should Ruby aim for programming share
within the rebel languages group? Sure, why not? Yes, Ruby should be as
well documented as the other three. But is achieving programming share
relative to Java or C++ as an “industrial strength general purpose
object oriented language” a realistic, achievable goal?
I wonder if the reason a lot of these things don’t happen is that matz
doesn’t really need them, and those that do, can’t agree on a syntax (or
elect a representative to make the decision for them). See below.
Trans wrote:
Binding.of_caller.
I’d really prefer something more flexible, like what Mauricio did, or
what Evan is doing with Rubinius.
object_class instead of class.
Interesting thought, but two things:
We could just fix it so you can say “class = …”. After all, local
variable “foo” and method call “self.foo” can coexist.
It breaks the Huffman principle (for that matter, so does the current
notation) that Tanaka A. cited at RubyConf '04. We use self.class a
heck of a lot more than object_id – why should its name be longer?
Allow a comma between the two alias arguments
I think the reason both alias and alias_method exist is because the
latter’s supposed to be limited to dynamic situations. Akin to def vs
define_method, undef vs undef_method, etc. That said, I’m ambivalent.
A block can’t take a block, nor default arguments. What kind of define_method is this? I realize this a trickier issue.
See 1.9.
Close the closures.
Interesting. Of course, the method author has the choice of calling
instance_eval. And, well,
def do!(&blk)
obj = Object.new
obj.define_method(:my_little_pony, &blk)
obj.method(:my_little_pony) #.to_proc, if you prefer
end
a = 1
dosomething &do! {|x|
p a
}
Another hassle when metaprogramming. #send should work
for public methods only!
See 1.9.
This one’s more of my own pet-peeve but nontheless, who wouldn’t want
a nice word alias for Class#===.
I’d like a nice word alias for Object#===. With Class#===, I prefer
using is_a? class.
I wonder if the reason a lot of these things don’t happen is that matz
doesn’t really need them, and those that do, can’t agree on a syntax (or
elect a representative to make the decision for them). See below.
Well, it be nice to know what matz thought.
Trans wrote:
Binding.of_caller.
I’d really prefer something more flexible, like what Mauricio did, or
what Evan is doing with Rubinius.
You mean a frame stack?
object_class instead of class.
Interesting thought, but two things:
We could just fix it so you can say “class = …”. After all, local
variable “foo” and method call “self.foo” can coexist.
Can it be done? Although, you loose access to the class in that case.
I’d rather have both.
It breaks the Huffman principle (for that matter, so does the current
notation) that Tanaka A. cited at RubyConf '04. We use self.class a
heck of a lot more than object_id – why should its name be longer?
But at the same time promotes duck typing
Allow a comma between the two alias arguments
I think the reason both alias and alias_method exist is because the
latter’s supposed to be limited to dynamic situations. Akin to def vs
define_method, undef vs undef_method, etc. That said, I’m ambivalent.
See 1.9.
Sure I know. But that’s like how many years away?
This one’s more of my own pet-peeve but nontheless, who wouldn’t want
a nice word alias for Class#===.
I’d like a nice word alias for Object#===. With Class#===, I prefer
using is_a? class.
However, it’s safer to ask the class since the object can more readily
“lie”.
Oh, and the spirit of Dave T. asks you to PDI.
That’s almost funny
Anyone else have any other common little things to add?
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:
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.
I completely agree here.
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.
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 define_method is this? I realize this a trickier issue.
But at some point the trick has to be performed.
+1
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!)
I agree that `funcall’ is a weird name… “call a function”. What
function? I thought we agreed on calling them methods!
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.
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!
+1
I think this is very much a situation where you can easily get by
without it and avoid ugliness / confusion.
I agree that `funcall’ is a weird name… “call a function”. What
function? I thought we agreed on calling them methods!
This is kind of interesting. I don’t know if matz had this in mind form
the beginning or only realized it later, but
function = private method
why? because a private method can’t be called with a receiver. it’s a
very interesting correlation, which makes excellent sense. however, I
agree with you, introducing this concept into the language via a single
meta-coding method called ‘funcall’ is rather odd, to say the least
(okay, we have module_function too, but that certainly doesn’t help
matters!!!)
I agree that `funcall’ is a weird name… “call a function”. What
function? I thought we agreed on calling them methods!
I think the idea is that calling methods without a receiver can be
considered “functional style”; therefore, “funcall”, rather than
“send”, should be understood to include private methods.
I’m not sure I find it very convincing. I think of the no-receiver
thing as a way of un-cluttering the code a bit, not a departure from
object orientation. After all, there is a receiver, and it is
receiving a message.
Also, funcall itself does involve a receiver. So the situation is
that you see this:
obj.funcall(:meth)
and you infer that it includes private methods because if you were
calling meth as a private method, there would be no receiver. To me
that involves too much “What if?”
and you infer that it includes private methods because if you were
calling meth as a private method, there would be no receiver. To me
that involves too much “What if?”
I agree that `funcall’ is a weird name… “call a function”. What
function? I thought we agreed on calling them methods!
I think the idea is that calling methods without a receiver can be
considered “functional style”; therefore, “funcall”, rather than
“send”, should be understood to include private methods.
I think “funcall” is just an artifact of the rb_funcall()
function—which invokes a method on an explicit receiver—from
Ruby’s C interface.
Yikes, a method that behaves differently depending on how it’s called?
What about method(:send).call vs self.method(:send).call?
Meprefers send_priv or something.
Devin
(And I think David was just trying to guess at the reasoning behind the
name “funcall” [I’d imagine better explained by rb_funcall], and then
disagreeing with the reasoning.)
obj.send(:foo) # will call only public
obj.send!(:foo) # will bypass private/protected, like the current
send.
reads better then funcall to me, at least.
Yes please. That’s perfect.
No please. That doesn’t match the behavior of any other #foo, #foo!
that I know of. #send and #funcall match what the written methods
look like perfectly.
that I know of. #send and #funcall match what the written methods
look like perfectly.
The problem with #send and #funcall (or #send!) is that these are VIMs
(very important methods). They aren’t to be overwritten lightly, if at
all, which is evident by the fact that we also have send in case
that it is. So any generic piece of meta-programming ends up using send anyway. Throw in funcall and now we have four methods when
two would do. So besides the fact that this straddles us with two
completely different terms for nearly the exact same thing, which is
bad enough, it does nothing to alleviate this more fundamental issue.
What about method(:send).call vs self.method(:send).call?
reads better then funcall to me, at least.
Me too – that was what I suggested long ago Matz didn’t feel it
corresponded to his concept of a ! (dangerous) method.
Matz didn’t feel it