On 1/14/07, Gavin K. [email protected] wrote:
Sorry about the top-reply; stupid Outlook email.
Do not worry this is PL so the ML conventions do not apply.
Just a few quick replies:
- Re the RCR - I should have been more clear; I was referring to the RCR
you filed (#pred) not the proposed one (#succ! and #pred!). I agree that
it’s totally subjective as to what is ‘compelling’ for the core or not; I
was just commenting that there didn’t seem to be any argument at all in the
RCR you file.
Ah that comes quite as a big surprise to me, there were two RCRs about
Integer#odd? and Integer#even? that were accepted by Matz without a
line of discussion, he likes it (I like it too BTW).
I think that instead of creating two new methods adding the symetrical
an existing that is #succ would be even more obviously a good idea and
really did not want to bother the community with it.
Saying that now, Icould have bothered the community with it instead of
#pred!, #succ! which is really stupid stuff, I will elaborate below…
Therefore I more or less copied the reasoning and format of the accepted
RCRs to the #pred RCR. I felt like somebody doing work so obvious that
nobody would do it because it was obvious.
(Just a little pun to recent discussions: maybe I should file an English
Change Request to add a ! to obvious as oubviously obvious is a
Maybe that explains why I was very lazy about that one.
Did I read you correctly that you do not feel that adding Integer#pred
symetrie to Integer#succ would be improving the orthogonality of Ruby (I
it in a simpler way in the RCR, a “naive” user would expect it to exist
after having seen succ for the first time, would she not?)
I think your idea about not arguing for or against your proposal on the
mailing list interesting. As an anecdote, I was a web designer in my
previous job. For a long time we struggled with how to present designs to a
client. On the one hand, the design ought to speak for itself; if it used
blue and gold to appeal to a rich old male demographic, then the client
ought to automatically get a sense that the design was appropriate for the
target audience just by looking at it. On the other hand, explicitly listing
all the design decisions and implications of them was usually more succesful
at selling the design as a good one to the client. I was always torn on the
issue, and see the parallel here.
I am a very bad communicator, I know lots of things in theory and
fail to apply it, slightly simplified: I never really learned to
That is bad, but I try to compensate by staying calm when people are
to me, I know it might be my fault…
Nevertheless integerated into a team I can do quite a little bit, if you
want to convince someone of something there is only one way, make her
am married that it was her idea. Not easy a task though.
- Perhaps its my mental model and not Ruby’s at fault here, but I don’t
how Ruby can be made to do what you suggest.
Me neither now, I was completely forgetting that x=42, y=42, x and y
reference the same object. I did not want to change 42 of course (you
but nobody could know after what I had written).
I can absolutely see that it would be possible to add “x++” as syntax
that is interpretted as “_tmp = x; x = x + 1; _tmp”.
Sure but I did not want to suggest that
I can further see that (as a pure syntax change) you could change the
interpretter to treat “x.succ!” specially, as a syntax shortcut (and not a
method call at all).
And that would be most ugly and inconsistent and I love consistency,
would not be any support for this, given the discussion on the ML.
However, in Ruby, variables do not contain values, they /reference/
(Forgive me if you already know this.) When you do:
I forgive you I wrote some stupid stuff not thinking about what I know
Ruby. I wanted the object x references being changed without being
There would be an implementation but I think it would be a performance
nightmare. Make Integers mutable objects that are cloned on write.
Just for the sake of theory:
x=42 (x.object_id = 85)
x.succ! (x.object_id=0x2389f0d0) a clone of 42 is created and
x== 43 && x==y (true)
No there is no need for that.
x = Foo.new
then the ‘x’ variable is pointing to the instance of the Foo class. When
you do “y=x” then the ‘y’ variable is set to point to that same instance in
memory. When you then do “x.bar” you are invoking the bar method with the
self not set to ‘x’, but to that instance in memory. When the method call
occurs, you lose all information about what variable (or array slot, or hash
value, etc.) you were talking about.
Sorry that I wasted your time but I appreciate the time you have taken
I hope that was clear. I suppose what I’m saying is:
“There’s no way without drastically changing the core of Ruby to implement
succ! as a method of the Fixnum or Integer classes. It could be treated
specially by changing the parser to treat it as syntax; I would personally
be very against implementing anything that looks like a method call
(particular a method with a name, and not an operator) as syntax.”
And finally: I have absolutely no objection if you want to post my
message, your reply, or this message to the mailing list.
Have a good day, and I do appreciate discussions on how to improve Ruby.
I will definitely put this stuff to the ML you have been most kind
all this time…