«

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

Thanks for bringing these slides to my attention. This one caught my
eye:
http://www.rubyist.net/~matz/slides/.../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">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".]
>
>

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

Trans wrote:
> This one caught my
>> eye:
>> http://www.rubyist.net/~matz/slides/.../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/wo...ation-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.

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

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

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.

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:
> * <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 12/30/06, Daniel Schierbeck <> 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!

+1

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

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.