Little Things

[7rans]

I was a bit surprised about Matz mention of the little things in his
last <a
href="http://www.rubyist.net/~matz/slides/rc2006/mgp00017.html">ketynote</a>.
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.

* <code>object_class</code> instead of </code>class</code>. I get sick
just looking at <code>self.class.foo</code>. And it prevents use of
"class" for other variables/methods. (Hence the all too frequent use of
"klass"). <code>object_class</code> on the other hand is nicely
analogous to <code>object_id</code>.

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

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

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

* A block can't take a block, nor default arguments. What kind of
<code>define_method</code> 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:

<pre>
  a = 1
  dosomething do! |x|
    p a #=> error
  end
</pre>

* Another hassle when metaprogramming. <code>#send</code> should work
for public methods only! There's a big issue with backward
compatibility here. I have the solution: <code>#object_send</code>.
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 <code>#funcall</code> for the alternate
private-accessing send is a <b>terrible</b> name, try
<code>#instance_send</code>. (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:

  <pre>
    MyClass.instance?(myobject)
  </pre>

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

[matt7 (matt)]

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

···

On Sun, 2006-12-31 at 02:27 +0900, Trans wrote:

I was a bit surprised about Matz mention of the little things in his
last <a
href="http://www.rubyist.net/~matz/slides/rc2006/mgp00017.html&quot;&gt;ketynote&lt;/a&gt;\.
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.

* <code>object_class</code> instead of </code>class</code>. I get sick
just looking at <code>self.class.foo</code>. And it prevents use of
"class" for other variables/methods. (Hence the all too frequent use of
"klass"). <code>object_class</code> on the other hand is nicely
analogous to <code>object_id</code>.

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

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

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

* A block can't take a block, nor default arguments. What kind of
<code>define_method</code> 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:

<pre>
  a = 1
  dosomething do! |x|
    p a #=> error
  end
</pre>

* Another hassle when metaprogramming. <code>#send</code> should work
for public methods only! There's a big issue with backward
compatibility here. I have the solution: <code>#object_send</code>.
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 <code>#funcall</code> for the alternate
private-accessing send is a <b>terrible</b> name, try
<code>#instance_send</code>. (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:

  <pre>
    MyClass.instance?(myobject)
  </pre>

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

[Devin_Mullins]

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.

* <code>object_class</code> instead of </code>class</code>.

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 Akira 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 <code>alias</code> 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
<code>define_method</code> 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. <code>#send</code> 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 Thomas asks you to PDI.

Devin

[Daniel_Schierbeck]

I mostly agree, with some of the additions of course being more
important than others.

* <code>object_class</code> instead of </code>class</code>. I get sick
just looking at <code>self.class.foo</code>. And it prevents use of
"class" for other variables/methods. (Hence the all too frequent use of
"klass"). <code>object_class</code> on the other hand is nicely
analogous to <code>object_id</code>.

I completely agree here.

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

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
<code>define_method</code> is this? I realize this a trickier issue.
But at some point the trick has to be performed.

+1

* Another hassle when metaprogramming. <code>#send</code> should work
for public methods only! There's a big issue with backward
compatibility here. I have the solution: <code>#object_send</code>.
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 <code>#funcall</code> for the alternate
private-accessing send is a <b>terrible</b> name, try
<code>#instance_send</code>. (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

···

On Sun, 2006-12-31 at 02:27 +0900, Trans wrote:

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

I'd like to see them as separated RCRs, even though the new RCR site
have not seen its successful start-up yet.

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

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.

By the way, YARV was committed in the Subversion trunk yesterday.

* <code>object_class</code> instead of </code>class</code>. I get sick
just looking at <code>self.class.foo</code>. And it prevents use of
"class" for other variables/methods. (Hence the all too frequent use of
"klass"). <code>object_class</code> on the other hand is nicely
analogous to <code>object_id</code>.

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.

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

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

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

* A block can't take a block, nor default arguments. What kind of
<code>define_method</code> is this? I realize this a trickier issue.
But at some point the trick has to be performed.

We have it in 1.9; well, at least partially.

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

* Another hassle when metaprogramming. <code>#send</code> should work
for public methods only! There's a big issue with backward
compatibility here. I have the solution: <code>#object_send</code>.
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 <code>#funcall</code> for the alternate
private-accessing send is a <b>terrible</b> name, try
<code>#instance_send</code>. (And yes, I'm begging here!)

We have send, funcall, __send, __send! in 1.9. Do we need more?

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

<pre>
   MyClass.instance?(myobject)
</pre>

But I'm not picky about what word to use as long as it's readable.

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.

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

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!)
are not the reason. Expected screams from all over the world suspends
incompatibility and behavior changing for 1.8.

              matz.

···

In message "Re: Little Things" on Sun, 31 Dec 2006 02:27:14 +0900, "Trans" <transfire@gmail.com> writes:

[Guest20 (Guest)]

When we're talking about little things, I've got one suggestion as
well. Python has the nice trick that you can call any object like a
function by simply overriding the __call__ method. Something like that
would be nice to have in Ruby as well. When you call an object with
the normal syntax, the fallback could be the #call method or some
such. Then it'd be possible to do this:

  def some_method(&proc)
    proc("Hello")
    proc "Hello"
    proc 1, 2, 3
  end

I admit that having a separate function namespace means that we can
have ice syntax for method calls with no parens, but something like
this would permit some cool tricks.

···

On 12/30/06, Trans <transfire@gmail.com> wrote:

I was a bit surprised about Matz mention of the little things in his
last <a
href="http://www.rubyist.net/~matz/slides/rc2006/mgp00017.html&quot;&gt;ketynote&lt;/a&gt;\.
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....
[...]

--
- Simen

[Ilan_Berci]

Trans wrote:

I was a bit surprised about Matz mention of the little things in his
last <a
href="http://www.rubyist.net/~matz/slides/rc2006/mgp00017.html&quot;&gt;ketynote&lt;/a&gt;\.
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....

First off great discussion and thank you kindly for posting the link!
Ironically, your first point about the discussion of the little things
vs Mat'z "the need for speed" has mostly gone untouched. I believe Matz
has brought up some excellent points in that slide show and that was the
first time I noticed his sense of urgency in getting the ball rolling on
1.9.

I should note before continuiing that I know nothing of the progress of
1.9 and haven't contributed in any way but like most am anxiously
looking forward to it!

My belief from reading that slide show is that the core team must be
getting hounded with suggestions, observations, complaints, etc... and
this is causing some considerable lag and frustration in it's life cycle
and this is a cry by the lead saying "Enough is enough!" I think he is
absolutely right, his team needs to push this thing out and then
formalize the process of change. IMO, they are pretty much forced to
accept a formalized process for change requests as there is now a lot of
momentum behind the language. I believe this is a key milestone for
Ruby hitting the big time.

I also really like his definition of Ruby as an "Agile" language! This
is a perfect definition and it seems so obvious after his statement.

As for the concerns over documentation, I believe it's need is too much
hyped about. Ruby is very intuitive by design and due to IRB and
metaprogramming, most of what one needs can be retreived quite easily
after reading a book or 2 and by coming here as I often do

He is not saying that we should stop talking about the little things,
but that we must concentrate on the big things in order that we keep up
and have a platform in which to add the little things later. A possible
analogy is a story I heard a few years back.

A professor placed a container on his desk and then proceeded to put
rocks into it, he continually placed smaller and smaller rocks into the
container as space would allow and then finally filled the remaining
space with sand. He then asked what the class learned from this
experiment.

One student exclaimed that the experiment simply showed that we can
always strive to fit more in.

The professor corrected the student and explained that if we don't do
the big things first, they will never be completed after perfoming all
the small things.

ilan

···

--
Posted via http://www.ruby-forum.com/\.

[7rans]

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.

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.

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.

[Devin_Mullins]

Duh... ignore this part.

Devin Mullins wrote:

···

Trans wrote:

* 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
}

[7rans]

Devin Mullins 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?

> * <code>object_class</code> instead of </code>class</code>.
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 Akira 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 <code>alias</code> 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 Thomas asks you to PDI.

That's almost funny

Anyone else have any other common little things to add?

T.

[Greg_Brown1 (Greg Brown)]

+1

I think this is very much a situation where you can easily get by
without it and avoid ugliness / confusion.

···

On 12/30/06, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:

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

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!

[7rans]

Daniel Schierbeck 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.

[David_A_Black3 (David A. Black)]

Hi --

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

···

On Sun, 31 Dec 2006, Daniel Schierbeck wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

[Eric_Hodel1 (Eric Hodel)]

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.

···

On Dec 30, 2006, at 14:47, Daniel Schierbeck wrote:

I agree that `funcall' is a weird name... "call a function". What
function? I thought we agreed on calling them methods!

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

[James_Edward_Gray_II]

If __send! is OK, can we have the alias send! as well? I thought we wanted the get away from method names like __this__.

James Edward Gray II

···

On Dec 31, 2006, at 12:34 PM, Yukihiro Matsumoto wrote:

We have send, funcall, __send, __send! in 1.9. Do we need more?

[Devin_Mullins]

Yukihiro Matsumoto wrote:

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

I take it you don't like meta_class, the most often proposed name for it. How about virtual_class, or singleton_class, or both?

irb(main):001:0> a=5; def a.foo; end
TypeError: can't define singleton method "foo" for Fixnum
         from (irb):1
irb(main):002:0> a=""; class Foo < (class << a; self end); end
TypeError: can't make subclass of virtual class
         from (irb):2

Devin
(Sorry, I don't know what's already been proposed. Shame on me for not researching it...)

[7rans]

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.

[David_A_Black3 (David A. Black)]

Hi --

My belief from reading that slide show is that the core team must be
getting hounded with suggestions, observations, complaints, etc... and
this is causing some considerable lag and frustration in it's life cycle
and this is a cry by the lead saying "Enough is enough!" I think he is
absolutely right, his team needs to push this thing out and then
formalize the process of change. IMO, they are pretty much forced to
accept a formalized process for change requests as there is now a lot of
momentum behind the language. I believe this is a key milestone for
Ruby hitting the big time.

Actually there's been a formalized process for several years:
http://www.rcrchive.net. It's recently been re-started, and there are
some differences in logistics (mailing lists instead of comments on
the site; more group participation in revision of RCR text). But the
basic components of the RCR, and the presence of a process, are not
new.

David

···

On Sat, 6 Jan 2007, Ilan Berci wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
    (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

[M_Edward_Ed_Borasky1 (M. Edward (Ed) Borasky)]

Trans wrote:

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.
    
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(P)
http://borasky-research.blogspot.com/

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

[Suraj_Kurapati1 (Suraj Kurapati)]

unknown wrote:

···

On Sun, 31 Dec 2006, Daniel Schierbeck 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.

--
Posted via http://www.ruby-forum.com/\.