Little Things


#1

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”.]


#2

Thanks for bringing these slides to my attention. This one caught my
eye:
http://www.rubyist.net/~matz/slides/rc2006/mgp00027.html

“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.

my .02

Matt


#3

matt wrote:

Thanks for bringing these slides to my attention.

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.

T.


#4

Trans wrote:

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”
(http://www.catb.org/~esr/writings/world-domination/world-domination-201.html),
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?


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.


#5

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.

Oh, and the spirit of Dave T. asks you to PDI.

Devin


#6

Duh… ignore this part. :stuck_out_tongue:


#7

Devin M. wrote:

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 :wink:

  • 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 :smiley:

Anyone else have any other common little things to add?

T.


#8

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!

Cheers,
Daniel


#9

On 12/30/06, Daniel S. removed_email_address@domain.invalid wrote:

  • 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.


#10

Daniel S. wrote:

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!!!)

T.


#11

Hi –

On Sun, 31 Dec 2006, Daniel S. wrote:

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?”

David


#12

removed_email_address@domain.invalid wrote:

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?”

Hmm… Are you perhpas indirectly suggesting:

send(:meth) # private
self.send(:meth) # public

?

T.


#13

unknown wrote:

On Sun, 31 Dec 2006, Daniel S. wrote:

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.


#14

Trans wrote:

Hmm… Are you perhpas indirectly suggesting:

send(:meth) # private
self.send(:meth) # public

?

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.)


#15

On Dec 30, 2006, at 14:47, Daniel S. wrote:

I agree that `funcall’ is a weird name… “call a function”. What
function? I thought we agreed on calling them methods!

Why? It looks like a function call as there is no receiver.

obj.foo() # method call, receiver is obj

foo() # function call, no receiver

private methods must be called like functions, not like methods.


Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!


#16

On 12/31/06, Devin M. removed_email_address@domain.invalid wrote:

Meprefers send_priv or something.

Devin

What about:

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.

  • Rob

#17

On Dec 31, 2006, at 24:04, Wilson B. wrote:

On 12/31/06, Rob S. removed_email_address@domain.invalid wrote:

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.


Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!


#18

On 12/31/06, Rob S. removed_email_address@domain.invalid wrote:

What about method(:send).call vs self.method(:send).call?
reads better then funcall to me, at least.
Yes please. That’s perfect.


#19

On Dec 31, 3:34 am, Eric H. removed_email_address@domain.invalid wrote:

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.

T.


#20

Hi –

On Sun, 31 Dec 2006, Rob S. wrote:

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 :slight_smile: Matz didn’t feel it
corresponded to his concept of a ! (dangerous) method.

David