#send in 1.9

Trans wrote:

Looking over 1.9’s change of #send, ie.

send doesn’t always call private methods anymore (#__send, #__send!,
#funcall)
ruby-talk:153672 It is still possible to call them with the newly
introduced #__send! and funcall methods.

Can I make a modest proposal? Can we preserve backward compatibility,
keeping #send as is, and instead pick a new name for the “proper”
public send?

This topic again? I’ve lost count of how many threads I’ve read about
the naming of send/funcall. Has anyone kept a full list of the numerous
suggestions? I can remember:

(public-only)
send
__send
send
object_send

(all)
funcall
send!
__send!
instance_send

Daniel

On 8/2/07, ronald braswell [email protected] 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 :).

On Aug 7, 7:00 am, Bira [email protected] wrote:

On 8/2/07, ronald braswell [email protected] 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.

On 8/7/07, Trans [email protected] 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. :-/

On Aug 7, 9:13 am, “Gregory B.” [email protected] wrote:

On 8/7/07, Trans [email protected] 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.

On 8/7/07, Trans [email protected] 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/

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.

On 8/7/07, Gregory B. [email protected] wrote:

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

On 8/7/07, Gregory B. [email protected] wrote:

send! but am fine with send / funcall()
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

On Aug 7, 11:14 am, “Gregory B.” [email protected] wrote:

On 8/7/07, Trans [email protected] 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.

T.

On 8/7/07, Robert D. [email protected] wrote:

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.

On 8/7/07, Trans [email protected] wrote:

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

( I have an RCR that recommends a compromise for Proc#yield that I’ve
not yet submitted)

Hi –

On Wed, 8 Aug 2007, Gregory B. wrote:

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

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 Aug 8, 3:59 am, [email protected] wrote:

Then write an RCR and see how it does. I personally prefer send /
popular stances filter up.
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.

T.

Hi –

On Wed, 8 Aug 2007, Trans wrote:

On Aug 7, 11:14 am, “Gregory B.” [email protected] wrote:

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? :slight_smile:

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 8/8/07, James Edward G. II [email protected] 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.

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

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 T. in protest? How often has that resulted in success,
just out of curiosity?

James Edward G. II

On 8/8/07, Robert D. [email protected] 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 :wink:

I think some well-focused finite wisdom might be more helpful, honestly.

On 8/8/07, Trans [email protected] wrote:

On Aug 7, 11:14 am, “Gregory B.” [email protected] wrote:

clearly arn’t worth the electrons they’re transmitted-by.
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 :wink:
Robert

On Aug 8, 4:59 am, [email protected] 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.

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 8/8/07, James Edward G. II [email protected] wrote:

clearly arn’t worth the electrons they’re transmitted-by.

So your strategy has been to lob regular change-the-language requests
at Ruby T. in protest? How often has that resulted in success,
just out of curiosity?

This is an attitude I cannot understand?
I have to recognize that valuable members like Gregory, David and
yourself have probably a point when they agree, out of pure
experience(1), but here I feel that I see things completely different.

For me this is a discussion beyond lobbying, and I feel it is rich,
and I feel sad that
you folks point a finger and cry RCR :slight_smile:
This is strange but it is the best way I can describe this, hmm I
promised I would not speak up on this anymore, but I am too intrigued,
so you can criticize my netiquette for sure :frowning:
Robert

(1) Experience also tells me that Tom’s ideas are worth thinking about
them, some I found strange or wrong, but not many…