From: Yossef Mendelssohn <ymendel@pobox.com>
Reply-To: ruby-talk@ruby-lang.org
To: ruby-talk@ruby-lang.org (ruby-talk ML)
Subject: Re: #send in 1.9
Date: Sat, 4 Aug 2007 00:18:36 +0900
> Will there be a compatability flag to allow1.9to act like 1.8 for cases in
> which backwards compatability was broken? That way you could take advantage
> of new features w/o having to rewrite an existing codebase all at once.
>
> Ron
That way lies the Perl path.
Don't get me wrong. I came to Ruby from Perl and I enjoyed it just
fine, but I'm much happier with Ruby. There are some things I don't
entirely agree with, but some of those are changing with 1.9. They're
changing to be better, which leads to breaking some code that depends
on the old behavior. Backwards compatibility is nice, but it's not so
important that you hobble progress.
--
-yossef
Thanks, Yossef.
Ron
···
On Aug 2, 4:10 pm, "ronald braswell" <rpbrasw...@hotmail.com> wrote:
But why change something if you don't need to? The issue here is
merely semantic, #send vs. #funcall. So why break all those previous
uses of #send, if all we need to do is pick a different term to
prevent it? Is the semantics of #send that crucial? That's really the
crux of my argument: Why change #send if you are just going to offer
the same functionality in another straight-forward method like #funcall.
Ruby has a general policy of giving long names to methods that
subverts formal OOP. So it really puzzles me that Matz would just pick
another simple term like 'funcall' (Lisp is great functionally, but
I'd certainly think twice before borrowing terms verbatim). If you
want something semantically "tight", I still think #send vs. #instance_send makes the most sense. It clearly fits in with the rest
of the instance_xxxxx methods. But short of that, I just don't see the
point --just pick another name. Indeed, there may even be a better
term. For instance what about #respond? That has a similar meaning to
send and has a nice correspondence to #respond_to? Or if you prefer
something a little shorter/not quite so clearly correspondent, how
about #reply?
In any case, the bottom line is that, of all the choices (in order of
my preference): #send vs. #instance_send, keep #send and pick a new
term, #send vs. #send!, ... Matz' current choice is at the bottom. And
I think a lot of Rubyists agree.
T.
T.
···
On Aug 7, 7:00 am, Bira <u.alber...@gmail.com> wrote:
On 8/2/07, ronald braswell <rpbrasw...@hotmail.com> wrote:
> Will there be a compatability flag to allow 1.9 to act like 1.8 for cases in
> which backwards compatability was broken? That way you could take advantage
> of new features w/o having to rewrite an existing codebase all at once.
My feeling is that so much is changing that, when backwards
compatibility is critical, you're better off sticking to 1.8. If you
think the new features are more important than that, you're going to
have to bite the bullet and port your code to work on 1.9 :).
I know , I thought it was worth a short +1, but we are not bad losers :))
Robert
···
On 8/2/07, Trans <transfire@gmail.com> wrote:
On Aug 2, 3:15 pm, "Robert Dober" <robert.do...@gmail.com> wrote:
> On 8/2/07, Trans <transf...@gmail.com> wrote:
>
> > Well, if my modest proposal doesn't carry, then I throw my hat in with
> > yours.
>
> Right, just let me hang in there all by myself, thanx
> R.
Lol. Well, I really did mean "if". So it's only half a hanging.
--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein
Then write an RCR and see how it does. I personally prefer send /
send! but am fine with send / funcall()
This discussion gets boring fast. :-/
···
On 8/7/07, Trans <transfire@gmail.com> wrote:
In any case, the bottom line is that, of all the choices (in order of
my preference): #send vs. #instance_send, keep #send and pick a new
term, #send vs. #send!, ... Matz' current choice is at the bottom. And
I think a lot of Rubyists agree.
> In any case, the bottom line is that, of all the choices (in order of
> my preference): #send vs. #instance_send, keep #send and pick a new
> term, #send vs. #send!, ... Matz' current choice is at the bottom. And
> I think a lot of Rubyists agree.
Then write an RCR and see how it does. I personally prefer send /
send! but am fine with send / funcall()
See how it does? You're clearly unaware of the current RCR state of
affairs.
This discussion gets boring fast. :-/
Er... then why are you reading this thread, let alone posting to it? I
don't think it's boring at all. It may seem a small matter to you, but
small things add up and effect the future of my favorite programming
language.
T.
···
On Aug 7, 9:13 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
For sure for those who like the behavior as it is planned...
Anyway a CR shall be discussed in this list before issued, so the
attitude, "write a RCR" because one does not want to discuss the item
is an approach I appreciate only mildly...
Nobody has forced you to get bored, right?
Imagine if I would drop a line into each thread I find boring, quite
awesome an idea.
Robert
···
On 8/7/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:
On 8/7/07, Trans <transfire@gmail.com> wrote:
> In any case, the bottom line is that, of all the choices (in order of
> my preference): #send vs. #instance_send, keep #send and pick a new
> term, #send vs. #send!, ... Matz' current choice is at the bottom. And
> I think a lot of Rubyists agree.
Then write an RCR and see how it does. I personally prefer send /
send! but am fine with send / funcall()
This discussion gets boring fast. :-/
--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein
> Then write an RCR and see how it does. I personally prefer send /
> send! but am fine with send / funcall()
See how it does? You're clearly unaware of the current RCR state of
affairs.
Please elaborate. I don't see an RCR open for this, or rejected, for
that matter. http://rcrchive.net/
> This discussion gets boring fast. :-/
Er... then why are you reading this thread, let alone posting to it? I
don't think it's boring at all. It may seem a small matter to you, but
small things add up and effect the future of my favorite programming
language.
My concern is that you bring up several issues that you wish to change
about Ruby, almost on a daily basis. I don't think it's a bad thing
(at all), I just think maybe focusing on a few key issues, making a
clear statement of why they matter to you, and then taking the
initiative to file an RCR would be more fruitful than complaining that
Matz isn't listening to people.
At least if you brought this discussion up in the form of an RCR,
you'd be able to get some definitive answers.
That's not what I'm suggesting. Search the archive for previous
discussions on this topic. My point is that sooner or later, issues
like this need to make it to the RCR phase to avoid repeating the same
points over and over.
···
On 8/7/07, Robert Dober <robert.dober@gmail.com> wrote:
On 8/7/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:
> On 8/7/07, Trans <transfire@gmail.com> wrote:
>
> > In any case, the bottom line is that, of all the choices (in order of
> > my preference): #send vs. #instance_send, keep #send and pick a new
> > term, #send vs. #send!, ... Matz' current choice is at the bottom. And
> > I think a lot of Rubyists agree.
>
> Then write an RCR and see how it does. I personally prefer send /
> send! but am fine with send / funcall()
>
> This discussion gets boring fast. :-/
For sure for those who like the behavior as it is planned...
Anyway a CR shall be discussed in this list before issued, so the
attitude, "write a RCR" because one does not want to discuss the item
is an approach I appreciate only mildly...
Hmm I do not understand, maybe it is me who is wrong, anyway I just
had not the feeling that this thread got repeating, yes ok Tom might
have made his point twice, but he was talking to different people and
I think that is quite ok, now you could make your point again too,
right?
Please note especially that Tom and myself have given in to the
majority POV -- so there will be no RCR I guess -- but that does not
imply that we feel wrong about our POV and can keep explaining it.
Ok enough said on this issue from my part.
Robert
···
On 8/7/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:
On 8/7/07, Robert Dober <robert.dober@gmail.com> wrote:
> On 8/7/07, Gregory Brown <gregory.t.brown@gmail.com> wrote:
> > On 8/7/07, Trans <transfire@gmail.com> wrote:
> >
> > > In any case, the bottom line is that, of all the choices (in order of
> > > my preference): #send vs. #instance_send, keep #send and pick a new
> > > term, #send vs. #send!, ... Matz' current choice is at the bottom. And
> > > I think a lot of Rubyists agree.
> >
> > Then write an RCR and see how it does. I personally prefer send /
> > send! but am fine with send / funcall()
> >
> > This discussion gets boring fast. :-/
> For sure for those who like the behavior as it is planned...
>
> Anyway a CR shall be discussed in this list before issued, so the
> attitude, "write a RCR" because one does not want to discuss the item
> is an approach I appreciate only mildly...
That's not what I'm suggesting. Search the archive for previous
discussions on this topic. My point is that sooner or later, issues
like this need to make it to the RCR phase to avoid repeating the same
points over and over.
--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein
The RCR system is in a rather anemic state. Honestly, it's not worth
the effort. It's better just to bring it up here and hope some of the
popular stances filter up.
T.
···
On Aug 7, 11:14 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
On 8/7/07, Trans <transf...@gmail.com> wrote:
> > Then write an RCR and see how it does. I personally prefer send /
> > send! but am fine with send / funcall()
> See how it does? You're clearly unaware of the current RCR state of
> affairs.
Please elaborate. I don't see an RCR open for this, or rejected, for
that matter.http://rcrchive.net/
Yeah, you're right. But I think that might be partially our fault for
never bringing things beyond RubyTalk
( I have an RCR that recommends a compromise for Proc#yield that I've
not yet submitted)
···
On 8/7/07, Trans <transfire@gmail.com> wrote:
On Aug 7, 11:14 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
> On 8/7/07, Trans <transf...@gmail.com> wrote:
>
> > > Then write an RCR and see how it does. I personally prefer send /
> > > send! but am fine with send / funcall()
>
> > See how it does? You're clearly unaware of the current RCR state of
> > affairs.
>
> Please elaborate. I don't see an RCR open for this, or rejected, for
> that matter.http://rcrchive.net/
The RCR system is in a rather anemic state. Honestly, it's not worth
the effort. It's better just to bring it up here and hope some of the
popular stances filter up.
Then write an RCR and see how it does. I personally prefer send /
send! but am fine with send / funcall()
See how it does? You're clearly unaware of the current RCR state of
affairs.
Please elaborate. I don't see an RCR open for this, or rejected, for
that matter.http://rcrchive.net/
The RCR system is in a rather anemic state. Honestly, it's not worth
the effort. It's better just to bring it up here and hope some of the
popular stances filter up.
Yeah, you're right. But I think that might be partially our fault for
never bringing things beyond RubyTalk
As far as I know, all the RCR process needs is people to submit RCRs.
If anyone knows of anything technically wrong with the site, please
let me know.
I think people were unhappy about Matz's decision to start from
scratch a little while back, but the process only exists in the first
place as a mechanism for Matz to get information and discuss ideas, so
it's really up to him if he wants people to resubmit.
David
···
On Wed, 8 Aug 2007, Gregory Brown wrote:
On 8/7/07, Trans <transfire@gmail.com> wrote:
On Aug 7, 11:14 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
I think that's what you technical adepts have never grasped. The
problem isn't technical, it's haptic.
But we've been threw this -- since the 2nd overhaul of the RCR
processes, let alone the third. For whatever reason, my critiques
clearly arn't worth the electrons they're transmitted-by.
T.
···
On Aug 8, 3:59 am, dbl...@rubypal.com wrote:
Hi --
On Wed, 8 Aug 2007, Gregory Brown wrote:
> On 8/7/07, Trans <transf...@gmail.com> wrote:
>> On Aug 7, 11:14 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
>>> On 8/7/07, Trans <transf...@gmail.com> wrote:
>>>>> Then write an RCR and see how it does. I personally prefer send /
>>>>> send! but am fine with send / funcall()
>>>> See how it does? You're clearly unaware of the current RCR state of
>>>> affairs.
>>> Please elaborate. I don't see an RCR open for this, or rejected, for
>>> that matter.http://rcrchive.net/
>> The RCR system is in a rather anemic state. Honestly, it's not worth
>> the effort. It's better just to bring it up here and hope some of the
>> popular stances filter up.
> Yeah, you're right. But I think that might be partially our fault for
> never bringing things beyond RubyTalk
As far as I know, all the RCR process needs is people to submit RCRs.
If anyone knows of anything technically wrong with the site, please
let me know.
I think people were unhappy about Matz's decision to start from
scratch a little while back, but the process only exists in the first
place as a mechanism for Matz to get information and discuss ideas, so
it's really up to him if he wants people to resubmit.
I think it also needs people to care enough to subscribe to RCRs,
review them, comment on them, and then for the submitters to have a
sense that someone in charge is actually going to do something with
the information.
My experience with the new RCR system hasn't been very negative, but
it hasn't been great. Previously (before the rest), I submitted a few
RCRs, there was lively discussion including by Matz, and in the end I
withdrew most of them. Someone (I assume Matz) actually marked some as
rejected. I wasn't crushed; I felt that I was part of an important
part of the process.
In the new RCR system, those RCRs I have submitted have gathered only
a few responses, a handful of votes, and now linger in the seeming
limbo of pending. It makes me feel like not enough people really care
about the RCR process to make it worth the time to officially work
through it.
I'm not sure what the root cause of these symptoms is. Did the reset
disenchant a bunch of people? Did the switch to mailing-list
subscription discussions raise the entry barrier too high?
I want the RCR process to work. I want to work with it. Maybe it's
gaining steam since I last visited it.
···
On Aug 8, 4:59 am, dbl...@rubypal.com wrote:
As far as I know, all the RCR process needs is people to submit RCRs.
If anyone knows of anything technically wrong with the site, please
let me know.
Then write an RCR and see how it does. I personally prefer send /
send! but am fine with send / funcall()
See how it does? You're clearly unaware of the current RCR state of
affairs.
Please elaborate. I don't see an RCR open for this, or rejected, for
that matter.http://rcrchive.net/
The RCR system is in a rather anemic state. Honestly, it's not worth
the effort. It's better just to bring it up here and hope some of the
popular stances filter up.
Yeah, you're right. But I think that might be partially our fault for
never bringing things beyond RubyTalk
As far as I know, all the RCR process needs is people to submit RCRs.
If anyone knows of anything technically wrong with the site, please
let me know.
I think people were unhappy about Matz's decision to start from
scratch a little while back, but the process only exists in the first
place as a mechanism for Matz to get information and discuss ideas, so
it's really up to him if he wants people to resubmit.
I think that's what you technical adepts have never grasped. The
problem isn't technical, it's haptic.
You want a touch screen?
But we've been threw this -- since the 2nd overhaul of the RCR
processes, let alone the third. For whatever reason, my critiques
clearly arn't worth the electrons they're transmitted-by.
No; they're just not higher on the list than what Matz asks me to do
with regard to RCRchive, which I really think is as it should be.
It's basically his project, written for him to his specifications. I
help out by writing and hosting it.
David
···
On Wed, 8 Aug 2007, Trans wrote:
On Aug 8, 3:59 am, dbl...@rubypal.com wrote:
On Wed, 8 Aug 2007, Gregory Brown wrote:
On 8/7/07, Trans <transf...@gmail.com> wrote:
On Aug 7, 11:14 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
I think that's what you technical adepts have never grasped. The
problem isn't technical, it's haptic.
Your prose got too flowery for me here. I looked up haptic, as I suspect you intended, and I still have no clue what you said.
But we've been threw this -- since the 2nd overhaul of the RCR
processes, let alone the third. For whatever reason, my critiques
clearly arn't worth the electrons they're transmitted-by.
So your strategy has been to lob regular change-the-language requests at Ruby Talk in protest? How often has that resulted in success, just out of curiosity?
Do not say that, they are, but it is a reasonable approach to give in
into the majority and not waste resources on an RCR that will fail.
That said I feel that these discussions are also a kind of an informal
CR process because Matz reads this, and how can he not be influenced
by our infinite wisdom
Robert
···
On 8/8/07, Trans <transfire@gmail.com> wrote:
On Aug 8, 3:59 am, dbl...@rubypal.com wrote:
> Hi --
>
>
>
> On Wed, 8 Aug 2007, Gregory Brown wrote:
> > On 8/7/07, Trans <transf...@gmail.com> wrote:
>
> >> On Aug 7, 11:14 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
> >>> On 8/7/07, Trans <transf...@gmail.com> wrote:
>
> >>>>> Then write an RCR and see how it does. I personally prefer send /
> >>>>> send! but am fine with send / funcall()
>
> >>>> See how it does? You're clearly unaware of the current RCR state of
> >>>> affairs.
>
> >>> Please elaborate. I don't see an RCR open for this, or rejected, for
> >>> that matter.http://rcrchive.net/
>
> >> The RCR system is in a rather anemic state. Honestly, it's not worth
> >> the effort. It's better just to bring it up here and hope some of the
> >> popular stances filter up.
>
> > Yeah, you're right. But I think that might be partially our fault for
> > never bringing things beyond RubyTalk
>
> As far as I know, all the RCR process needs is people to submit RCRs.
> If anyone knows of anything technically wrong with the site, please
> let me know.
>
> I think people were unhappy about Matz's decision to start from
> scratch a little while back, but the process only exists in the first
> place as a mechanism for Matz to get information and discuss ideas, so
> it's really up to him if he wants people to resubmit.
I think that's what you technical adepts have never grasped. The
problem isn't technical, it's haptic.
But we've been threw this -- since the 2nd overhaul of the RCR
processes, let alone the third. For whatever reason, my critiques
clearly arn't worth the electrons they're transmitted-by.
--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein
My experience with the new RCR system hasn't been very negative, but
it hasn't been great.
I agree that the new system hasn't won me over yet and I think you do a great job of analyzing the reasons.
I'm not sure what the root cause of these symptoms is. Did the reset
disenchant a bunch of people?
I can't speak for everyone, but it did for me a little, yes. After literally years of silent observation I finally got up the courage to make one. I followed the process as best I knew how: held the discussion on Ruby Core, etc. My proposal got 14 "In favor" votes and 4 "Strongly advocate" votes. Sadly, I think the site was already dead by then and it just didn't seem to matter.
Did the switch to mailing-list subscription discussions raise the entry barrier too high?
This does concern me too. I'll confess that I'm not auto-subscribed to all the lists as they are made. That felt like it could get overwhelming fast and I chickened out. (Looking back now though, the traffic has been fine, so far.)
Like most Prag fans I've been dipping into Erlang a little lately. One thing I noticed about their world was that they have one mailing list that was just for discussing proposals to change the language. I thought that was neat idea when I saw it. For some reason it feels less overwhelming to me.
David hit the nail on the head. RCRs would catch on a whole lot more
if we had a touch screen. Like the bottle exchange at the
supermarket, see how user friendly those are/
···
On 8/8/07, James Edward Gray II <james@grayproductions.net> wrote:
On Aug 8, 2007, at 9:52 AM, Trans wrote:
> I think that's what you technical adepts have never grasped. The
> problem isn't technical, it's haptic.
Your prose got too flowery for me here. I looked up haptic, as I
suspect you intended, and I still have no clue what you said.
I think some well-focused finite wisdom might be more helpful, honestly.
···
On 8/8/07, Robert Dober <robert.dober@gmail.com> wrote:
That said I feel that these discussions are also a kind of an informal
CR process because Matz reads this, and how can he not be influenced
by our infinite wisdom
