[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: #send in 1.9

ronald braswell

8/2/2007 9:11:00 PM

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.

Ron


>From: Ari Brown <ari@aribrown.com>
>Reply-To: ruby-talk@ruby-lang.org
>To: ruby-talk@ruby-lang.org (ruby-talk ML)
>Subject: Re: #send in 1.9
>Date: Fri, 3 Aug 2007 06:01:25 +0900
>
>
>On Aug 2, 2007, at 12:30 PM, Tim Pease wrote:
>
>>Matz has been stating over the past year that 1.9 will break backwards
>>compatibility with 1.8, and #send is just one of the changes.
>>String#[] has changed such that requesting a single character returns
>>a new String (it returns a Fixnum in 1.8). And there are others.
>>
>>The only way to make sure your code is going to work in 1.9 is to
>>test, test, test. And when you're done testing, then do some more
>>testing.
>
>crapzor! So there's no guide (yet) for making 1.9 suitable code?
>
>
>And does anyone know of a release for 2.0? I'm getting pretty psyched to
>countdown the days until.
>
>Thanks,
>-------------------------------------------------------|
>~ Ari
>crap my sig won't fit
>
>

_________________________________________________________________
Messenger Café ? open for fun 24/7. Hot games, cool activities served daily.
Visit now. http://cafemessenger.com?ocid=TXT_TAGHM_Au...
42 Answers

Yossef Mendelssohn

8/3/2007 3:19:00 PM

0

On Aug 2, 4:10 pm, "ronald braswell" <rpbrasw...@hotmail.com> wrote:
> 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

Bira

8/7/2007 2:01:00 PM

0

On 8/2/07, ronald braswell <rpbraswell@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 :).

--
Bira
http://compexplicita.bl...
http://sinfoniaferida.bl...

Trans

8/7/2007 4:03:00 PM

0



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

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.

Gregory Brown

8/7/2007 4:14:00 PM

0

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

Trans

8/7/2007 5:41:00 PM

0



On Aug 7, 9:13 am, "Gregory Brown" <gregory.t.br...@gmail.com> wrote:
> On 8/7/07, Trans <transf...@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()

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.

Gregory Brown

8/7/2007 6:14:00 PM

0

On 8/7/07, Trans <transfire@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://rcr...

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

Robert Dober

8/7/2007 7:37:00 PM

0

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

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
--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein

Gregory Brown

8/7/2007 7:44:00 PM

0

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.

Robert Dober

8/7/2007 8:14:00 PM

0

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.

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


--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein

Trans

8/7/2007 11:04:00 PM

0



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

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.