#send in 1.9
Trans
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? I think it would be much better to keep backward
compatibity rather than stress over exact terms ( yes, I'm learning to
make the tough choices ;-) There doesn't seem any good reason to
change how #send works if we are just going to have the same
functionality in another ordinary method, ie. #funcall.
As for a name for the new method, I know #call won't do b/c of Proc,
unless we want to make an exception for Proc and Proc-like objects --
which seems a viable option. But I'm sure their are other good choices
too.
T.
James Edward Gray II
> There doesn't seem any good reason to
> change how #send works if we are just going to have the same
> functionality in another ordinary method, ie. #funcall.
Well, there's the reason of the name of the method. You "send" an
object a message and you shouldn't be allowed to send private messages.
James Edward Gray II
Tim Pease
>
> Can I make a modest proposal? Can we preserve backward compatibility,
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.
Blessings,
TwP
dbl...@rubypal.com
You're allowed to send any message; it's up to the object what to do
with it :-) You could similarly say that you can only call
non-private functions.
In fact, the problem for me is that the names don't tell you what's
happening; you just have to know. For that reason, I would like to
see simply send/send! (and __send/__send!). But I think I lost that
argument a long time ago.
David
--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
Pit Capitain
> In fact, the problem for me is that the names don't tell you what's
> happening; you just have to know. For that reason, I would like to
> see simply send/send! (and __send/__send!). But I think I lost that
> argument a long time ago.
FWIW, I also think these would be the most Rubyish names. Please,
Matz, reconsider David's proposal!
---
To Tom and others using #send to call private methods: if the method
name is known, then you should immediately change
obj.send("method", *args)
to
obj.instance_eval { method(*args) }
IMO, this should be the "official" idiom to call a private method. It
works today and it will work with future versions of Ruby. Use #send
only if the method name has to be determined at runtime.
Regards,
Pit
Robert Dober
will of course depend on the amount of change.
After having read this thread I still go for backing up Tom. Please do
not change the behavior of Object#send, IMHO it is not worth it.
If it changes we will of course survive, err maybe, err I hope ;).
Robert
> Blessings,
> TwP
>
>
--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein
Robert Dober
> 2007/8/2, dbl...@rubypal.com <dbl...@rubypal.com>:
> > In fact, the problem for me is that the names don't tell you what's
> > happening; you just have to know. For that reason, I would like to
> > see simply send/send! (and __send/__send!). But I think I lost that
> > argument a long time ago.
>
> FWIW, I also think these would be the most Rubyish names. Please,
> Matz, reconsider David's proposal!
>
> ---
>
> To Tom and others using #send to call private methods: if the method
> name is known, then you should immediately change
>
> obj.send("method", *args)
>
> to
>
> obj.instance_eval { method(*args) }
In that case you should change even if the method name is unknown
obj.instance_eval { send( method, *args) }
Thx for the tip however.
>
Robert
Trans
On Aug 2, 12:32 pm, dbl...@rubypal.com wrote:
> Hi --
>
> On Fri, 3 Aug 2007, James Edward Gray II wrote:
>
> > On Aug 2, 2007, at 10:54 AM, Trans wrote:
>
> >> There doesn't seem any good reason to
> >> change how #send works if we are just going to have the same
> >> functionality in another ordinary method, ie. #funcall.
>
> > Well, there's the reason of the name of the method. You "send" an object a
> > message and you shouldn't be allowed to send private messages.
>
> You're allowed to send any message; it's up to the object what to do
> with it :-) You could similarly say that you can only call
> non-private functions.
>
> In fact, the problem for me is that the names don't tell you what's
> happening; you just have to know. For that reason, I would like to
> see simply send/send! (and __send/__send!). But I think I lost that
> argument a long time ago.
Well, if my modest proposal doesn't carry, then I throw my hat in with
yours.
T.
Dan Yoder
http://dev.zeraweb.com/design-blog-14/
My experience with this is that Matz is doing the right thing. It is
counterintuitive that sending a message to an object should bypass the
guidelines set by the class author. Given that 1.9 is willing to
sacrifice backwards compatibility in order to improve the language, I
don't really see a problem with fixing this semantic mismatch.
Minor sidebar: One thing I think is a little confusing is the version
numbering. Normally, you wouldn't expect a minor release version to
break backwards compatibility. I am not familiar with the roadmap, but
as a Ruby user, I find this a bit confusing. I wonder if people will
upgrade too quickly, not realizing what they are getting into.
This is particularly relevant to send, since I think changing send's
semantics can introduce some very subtle bugs that might not show up
right away. For example, a use of send that invokes a private method
will now invoke method_missing, which in turn might do something that
seems reasonable but is not the intended behavior.
Dan
Trans
On Aug 2, 12:32 pm, dbl...@rubypal.com wrote:
> Hi --
>
> On Fri, 3 Aug 2007, James Edward Gray II wrote:
>
> > On Aug 2, 2007, at 10:54 AM, Trans wrote:
>
> >> There doesn't seem any good reason to
> >> change how #send works if we are just going to have the same
> >> functionality in another ordinary method, ie. #funcall.
>
> > Well, there's the reason of the name of the method. You "send" an object a
> > message and you shouldn't be allowed to send private messages.
>
> You're allowed to send any message; it's up to the object what to do
> with it :-) You could similarly say that you can only call
> non-private functions.
>
> In fact, the problem for me is that the names don't tell you what's
> happening; you just have to know.
I agree. A rose smells just as sweet . . .
I just hate the thought of all the programs that will break for what
seems like a rather minor distinction in semantics.
T.
Robert Dober
> 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.
Trans
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.
T.
Robert Dober
Robert
Ari Brown
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
ronald braswell
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
_________________________________________________________________
Messenger Café — open for fun 24/7. Hot games, cool activities served daily.
Visit now. http://cafemessenger.com?ocid=TXT_TAGHM_AugHMtagline
Daniel DeLorme
> 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
Trans
On Aug 2, 9:05 pm, Daniel DeLorme <dan...@dan42.com> wrote:
>
> 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
Not quite. This time I'm asking that we do the opposite. Pick a new
name for "public send" and leave the old one alone. (Of course,
possibly someone else suggested it before, but I don't recall).
T.
Joel VanderWerf
> 2007/8/2, dbl...@rubypal.com <dbl...@rubypal.com>:
>> In fact, the problem for me is that the names don't tell you what's
>> happening; you just have to know. For that reason, I would like to
>> see simply send/send! (and __send/__send!). But I think I lost that
>> argument a long time ago.
>
> FWIW, I also think these would be the most Rubyish names. Please,
> Matz, reconsider David's proposal!
David's proposal always made sense to me, too. The send/funcall
distinction just doesn't sing out its meaning to me.
> To Tom and others using #send to call private methods: if the method
> name is known, then you should immediately change
>
> obj.send("method", *args)
>
> to
>
> obj.instance_eval { method(*args) }
That rewrite can be a source of errors if instead of "args" you have
some expression that depends on self:
obj.send("method", x, y) # x and y are methods of self
can be rewritten as:
args = [x, y]
obj.instance_eval { method(*args) }
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Pit Capitain
> Pit Capitain wrote:
> > To Tom and others using #send to call private methods: if the method
> > name is known, then you should immediately change
> >
> > obj.send("method", *args)
> >
> > to
> >
> > obj.instance_eval { method(*args) }
>
> That rewrite can be a source of errors if instead of "args" you have
> some expression that depends on self:
>
> obj.send("method", x, y) # x and y are methods of self
>
> can be rewritten as:
>
> args = [x, y]
> obj.instance_eval { method(*args) }
Good catch, Joel. It never happened to me, but you're right: the two
snippets I've shown are not equivalent. Thanks for pointing this out.
Regards,
Pit
Yossef Mendelssohn
> 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
ronald braswell
>From: Yossef Mendelssohn <yme...@pobox.com>>Date: Sat, 4 Aug 2007 00:18:36 +0900
Thanks, Yossef.
Ron
_________________________________________________________________
Puzzles, trivia teasers, word scrambles and more. Play for your chance to
win! http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink
Bira
> 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.blogspot.com
http://sinfoniaferida.blogspot.com
Trans
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
> 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
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
> > 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.
Robert Dober
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.
Gregory Brown
> On 8/7/07, Gregory Brown <gregory...@gmail.com> wrote:
> > On 8/7/07, Trans <tran...@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
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.
Trans
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.
T.
Gregory Brown
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)
dbl...@rubypal.com
On Wed, 8 Aug 2007, Gregory Brown wrote:
> On 8/7/07, Trans <tran...@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.
David
--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
Trans
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.
T.
dbl...@rubypal.com
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.
James Edward Gray II
> 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?
James Edward Gray II
Gregory Brown
> 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/
Robert Dober
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 ;)
Gregory Brown
> 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 ;)
I think some well-focused finite wisdom might be more helpful, honestly.
Robert Dober
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 :)
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 :(
Robert
(1) Experience also tells me that Tom's ideas are worth thinking about
them, some I found strange or wrong, but not many....
Phrogz
> 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.
James Edward Gray II
> 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 :)
I apologize. I should have been nicer.
You're right in that there's nothing really wrong with this
discussion. My personal feeling is that Trans's solution to most
situations is to change Ruby to fit his world view. I feel like it
should be the other way around most of the time.
His regular change requests have led me to consider them more noise
than signal, though I shouldn't have taken that out on this thread.
Again, I apologize.
Getting back on topic: I feel as I have already stated that send()
and funcall() are on the right sides of the equation. send() sends
messages to an object and I feel that should be treated as a normal
method call, ignoring the private stuff.
funcall() was selected because Matz sometimes refers to receiverless
method calls as a "function style" syntax. We have at least
module_function() in the language today as another sign of this.
Like David Black, I don't care for the name and would prefer send!
(). The bang is suppose to indicate a dangerous alternative and
using a send()-like tool to bypass method visibility feels dangerous
to me. You better know what you are doing.
Regardless though, I can't build any rational for reversing them,
beyond backwards compatibility with the current send(). While that's
a noble goal, 1.9 is known to break compatibility when needed and if
that leads to a better thought-out API, I'm for it.
funcall() makes zero sense on the other side of the equation, so now
we need a name change too. To me, that's one of the signs that this
suggestion is on the wrong path.
That's just my opinion though. I could be wrong and I definitely
don't make these decisions.
James Edward Gray II
James Edward Gray II
> 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.
James Edward Gray II
Trans
On Aug 8, 9:11 am, James Edward Gray II <ja...@grayproductions.net>
wrote:
James,
> 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.
That is what I have been suggesting for years now -- a dedicated
mailing list and a wiki for the community to jointly develop RCRs on.
It also wouldn't hurt if there were some sort of stated protocols,
about what happens if an RCR gets substantial support by the
community.
T.
Robert Dober
I guess UR right a Wiki would just do great :)
That at least I have learned from this discussion ...
Robert
Phrogz
> On 8/8/07, Trans <transf...@gmail.com> wrote:
> > That is what I have been suggesting for years now -- a dedicated
> > mailing list and a wiki for the community to jointly develop RCRs on.
> > It also wouldn't hurt if there were some sort of stated protocols,
> > about what happens if an RCR gets substantial support by the
> > community.
> I guess UR right a Wiki would just do great :)
> That at least I have learned from this discussion ...
> Robert
Interesting - I disagree. I very much like the idea of a single
champion with his/her own personal vision for an RCR. I'd not like to
put forth a well-thought-out design, and have some random chump come
in and decide that he personally thinks it should be different and
migrate my RCR to something different. Sure, I could vigilantly watch
my page and fight with the misguided fool in version control, but that
would turn me off more than the current system.
I like the idea of a single mailing list. I like the idea of a single
discussion thread (nested or not) per RCR, where modifications to the
proposal may be suggested. I don't like the idea of letting everyone
put their grubby little hands all over my spec. :)
Trans
On Aug 8, 8:57 am, James Edward Gray II <ja...@grayproductions.net>
wrote:
> You're right in that there's nothing really wrong with this
> discussion. My personal feeling is that Trans's solution to most
> situations is to change Ruby to fit his world view. I feel like it
> should be the other way around most of the time.
I admit that in the past I haven't been as self-critiquing of some of
my thoughts as perhaps I should, prior to posting them to this list.
But that's been quite some time ago. Nowadays, my posts in this regard
and fewer and a bit more thoughtful. Nonetheless, I still post more
than others on these matters b/c it interests me. Unfortunately there
has never been a dedicated forum for these discussions. I always get
flack on ruby-dev: "this is the not the place for this discussion",
and I get flack here for being too much noise. I just have to accept
that I am an individual, with my own approach to things, and often
enough, for whatever reason, they're "controversial". Nonetheless, I
like to think my individualism adds, on the whole, positively to this
collective.
T.
Trans
On Aug 8, 8:15 am, James Edward Gray II <ja...@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.
Sorry, by "haptic" I meant the "hands-on" nature of the system. Maybe
"ergonomic" would have been a better word. In any case, I simply mean
that the system is not inviting b/c it is not conducive to the
process.
T.
Trans
Oh, I agree with you. There would have to still "owners" of an RCR. If
the honor system wasn't enough --and I guess ultimately it's not, then
the admins of an RCR would have to grant permissions for others to
work on it.
T.
Gregory Brown
+1, right on.
Robert Dober
than here I feel that a Wiki is a good choice and that the problems
you are afraid of are unlikely to happen.
And it can be exactly as what you liked in the thread based
discussion, the RCR will be writeable by the author and some admins
only, and everybody else will just join the discussion page of the
RCR, what'd you think about that format, I feel it would be one
possible approach.
Cheers
Robert Dober
behavior, or are you thinking about ruby-core, please kindly evaluate
the format I suggested in my reply to Phrogz.
Robert Dober
words. I guess that even Tom will appreciate them, but he'd rather say
that himself.
Ok I did just not share that POV, I feel that Tom is a dreamer,
dreaming out loudly, for me the signal/noise ration was good but I am
a dreamer too ;).
Please note that he gave in very fast, I really think he did no
lobbying. But I understand now why you(plural form) are annoyed with
this post.
May I make a suggestion, let us be a little more liberal about
expressing wishes and visions on this list and OTH post to ruby-core
when we are serious, than of course on ruby-core this discussion would
have been annoying,
While on this list people not interested could have ignored it without
being afraid that something is going to change the language.
Well with being less afraid at least;)
Just a thought of course.
Robert
Gregory Brown
> Please note that he gave in very fast, I really think he did no
> lobbying. But I understand now why you(plural form) are annoyed with
> this post.
James said lob. Not lobby. :)
As in "Lob a big old slab of Chunky Bacon over to those Cartoon Foxes.
They look hungry!"
Robert Dober
> On 8/8/07, Robert Dober <robert...@gmail.com> wrote:
>
> > Please note that he gave in very fast, I really think he did no
> > lobbying. But I understand now why you(plural form) are annoyed with
> > this post.
>
> James said lob. Not lobby. :)
>
> As in "Lob a big old slab of Chunky Bacon over to those Cartoon Foxes.
> They look hungry!"
Todd Benson
<some really cool POVs>
I've read this read. I totally respect everybody's opinion in this
forum. You guys/gals are truly masters of turning what at first
appears to be a train wreck into something profound (Trans, James,
Robert, Gregory, David to name only a few of you great people). But
please, please don't get elitist on us lowly programmers.
I'm seeing a "sectioning off" of rubyists from nubyists, and I'm a
little frustrated when people start talking about "oh, we should
really bring this up in this other list".
I'm just venting. And I'm attaching myself to this particular thread
because of the signal to noise ratio that, for many of you, seems to
be a festering wound, when, in fact, it could be a blossoming flower.
My 1 cent (but I would like to think it's worth more than that).
Todd
Gregory Brown
> On 8/9/07, Robert Dober <robert...@gmail.com> wrote:
>
> <some really cool POVs>
>
> I've read this read. I totally respect everybody's opinion in this
> forum. You guys/gals are truly masters of turning what at first
> appears to be a train wreck into something profound (Trans, James,
> Robert, Gregory, David to name only a few of you great people). But
> please, please don't get elitist on us lowly programmers.
I don't think that's the intention. At least, I wouldn't want to do
that with my contributions here.
> I'm seeing a "sectioning off" of rubyists from nubyists, and I'm a
> little frustrated when people start talking about "oh, we should
> really bring this up in this other list".
To some extent I see the same thing, but it doesn't have to be that
way, and I'd rather it not be. I've held the view that RubyTalk is
highly valuable for discussions and getting ideas, but can be somewhat
unwieldy when it comes to decision making.
I totally think that it's worth discussing RCRs before submitting them
here, getting everyone's opinions, not just some group of Illuminati
hoarding all the Ruby secrets.
That having been said (and maybe it's not so apparent to newer
members), every once in a while the same potential RCR becomes a
recurring topic, with only slightly new opinions showing up in each
one. That's what my original comment about the topic being boring
was. I was more saying, 'let's bring this discussion to a place where
some decisions can be made, since this has come up so much before'.
I can see how that might seem a little abrupt without some context,
and maybe I also chose my words poorly. I think if anything what this
thread has exposed is that the RCR process may need some revamping so
that it feels more inviting to people, and so that we can get some
direct discourse going with the folks who can really make these
changes, the Ruby core team.
No disrespect to whoever mentioned that Matz reads RubyTalk, but
although that may be true, I wouldn't want to put the onus on him to
keep an eye out for discussion here. It's hard enough for your
average hacker to keep up on posts here, let alone someone responsible
for the language we're all here because of. :)
So I guess what I'm saying is that although some folks find the
possibilities of RubyTalk endless, I think the advantages are a little
more limited. It'd be great to say that all decisions could be made
in the middle of a crowded bazaar, but it's just not pragmatic, even
in open source communities.
So I hope that we can use RubyTalk for what it's good for, drumming up
ideas, sharing discussions, solving problems that scale to this level
of traffic with the diverse skill levels of folks subscribed here.
However, I get worried when valuable ideas come up over and over again
but never make it to the next level where they can be acted upon.
Hopefully that makes some sense.
> I'm just venting. And I'm attaching myself to this particular thread
> because of the signal to noise ratio that, for many of you, seems to
> be a festering wound, when, in fact, it could be a blossoming flower.
Sure, I really don't see the noise here to be a wound, I just feel
like there is a lot of worthwhile discussion that just ends up in the
wrong place. This thread happened to be one of them.
-greg
dbl...@rubypal.com
On Fri, 10 Aug 2007, Todd Benson wrote:
> On 8/9/07, Robert Dober <robert...@gmail.com> wrote:
>
> <some really cool POVs>
>
> I've read this read. I totally respect everybody's opinion in this
> forum. You guys/gals are truly masters of turning what at first
> appears to be a train wreck into something profound (Trans, James,
> Robert, Gregory, David to name only a few of you great people). But
> please, please don't get elitist on us lowly programmers.
>
> I'm seeing a "sectioning off" of rubyists from nubyists, and I'm a
> little frustrated when people start talking about "oh, we should
> really bring this up in this other list".
I think you're misreading the signals. The other-list talk is about
the RCR (Ruby Change Request) process, to which there's a whole
history. It's not about exclusionary tactics on ruby-talk. Really,
browse through some of the archives of this list and you'll see that
this list really isn't like that :-)
Todd Benson
> Hi --
>
> On Fri, 10 Aug 2007, Todd Benson wrote:
>
> I think you're misreading the signals.
You might be right about that.
> The other-list talk is about
> the RCR (Ruby Change Request) process, to which there's a whole
> history. It's not about exclusionary tactics on ruby-talk. Really,
> browse through some of the archives of this list and you'll see that
> this list really isn't like that :-)
These are sentiments I've had about ruby-talk long before this thread.
I can't speak for every other nuby, obviously, but I thought I might
take my chance and throw in thoughts that others share, briefly, and
in an obscure thread. Maybe I shouldn't have done that :)
The RCR list has its own frustrations. But when I read the original
post, what I saw was a frustration with Ruby in general. And it
seemed to me to become a "don't ask don't tell" attitude from
responders.
Ruby has a life of its own, obviously. And, I'll get used to that
fact. Just as long as the people I trust (like yourself) don't
abandon people like me. I've been a member of many newgroups, but
I've never seen such a scary mixture of free will and danger and
happiness and sorrow. Maybe that's a good thing.
>
> David
Todd
Gregory Brown
> The RCR list has its own frustrations. But when I read the original
> post, what I saw was a frustration with Ruby in general. And it
> seemed to me to become a "don't ask don't tell" attitude from
> responders.
I think that many of us are relying on our knowledge of previous
discussions that are in the archive. Maybe that's what makes you feel
that way?
I'm trying to understand what's bothering you about the discussion
here, in hopes that we can understand what the problem is.
Robert Dober
> > Hi --
> >
> > On Fri, 10 Aug 2007, Todd Benson wrote:
> >
> > I think you're misreading the signals.
>
> You might be right about that.
>
> > The other-list talk is about
> > the RCR (Ruby Change Request) process, to which there's a whole
> > history. It's not about exclusionary tactics on ruby-talk. Really,
> > browse through some of the archives of this list and you'll see that
> > this list really isn't like that :-)
>
> These are sentiments I've had about ruby-talk long before this thread.
> I can't speak for every other nuby, obviously, but I thought I might
> take my chance and throw in thoughts that others share, briefly, and
> in an obscure thread. Maybe I shouldn't have done that :)
us at least to clarify some potential misunderstandings, I can only
agree with what David and Gregory have said, the RCR would not be
elitist at all, just something specific but open for everyone, there
are RCRs that are so simple (mine BTW ;) that everybody can understand
them and there are others I do not understand.
>
> The RCR list has its own frustrations. But when I read the original
> post, what I saw was a frustration with Ruby in general.
better, but we are all very happy with Ruby, just that sometime we
want it to be perfect.
Maybe Tom and myself are indeed passing on a negative image of Ruby in
our quest for perfection, which cannot exist anyway [BTW Gregory that
was what I meant with "inifinite wisdom, inifinite as in a negative
exponent" and maybe Gregory and James did well to point that out a
little bit, but I did not read those subtle signals in the first place
:(
> And it
> seemed to me to become a "don't ask don't tell" attitude from
> responders.
talked it out nicely, and that counts most.
>
> Ruby has a life of its own, obviously. And, I'll get used to that
> fact. Just as long as the people I trust (like yourself) don't
> abandon people like me. I've been a member of many newgroups, but
> I've never seen such a scary mixture of free will and danger and
> happiness and sorrow. Maybe that's a good thing.
>
> Todd
>
>
Robert
Todd Benson
> I think that many of us are relying on our knowledge of previous
> discussions that are in the archive. Maybe that's what makes you feel
> that way?
I guess so.
> I'm trying to understand what's bothering you about the discussion
> here, in hopes that we can understand what the problem is.
I'm not asking for help, I'm just venting. That's all. It's just
that the community seems to be a bit volatile. It probably has
nothing to do with the language itself.
Todd Benson
> > fact. Just as long as the people I trust (like yourself) don't
> > abandon people like me. I've been a member of many newgroups, but
> > I've never seen such a scary mixture of free will and danger and
> > happiness and sorrow. Maybe that's a good thing.
> I believe it is indeed :)
> >
> > Todd
> >
> >
> Robert
Thanks, Robert. We're not even talking about code, and you still
heard me out. I appreciate it.
Todd