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
single
line of discussion, he likes it (I like it too BTW).
I think that instead of creating two new methods adding the symetrical
for
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
the
#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
dangerous
word)
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
as a
symetrie to Integer#succ would be improving the orthogonality of Ruby (I
put
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
miserably
fail to apply it, slightly simplified: I never really learned to
listen.
That is bad, but I try to compensate by staying calm when people are
harsh
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
(yes I
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
see
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
see
but nobody could know after what I had written).
I can absolutely see that it would be possible to add āx++ā as syntax
sugar
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,
there
would not be any support for this, given the discussion on the ML.
However, in Ruby, variables do not contain values, they /reference/
objects.
(Forgive me if you already know this.) When you do:
I forgive you I wrote some stupid stuff not thinking about what I know
about
Ruby. I wanted the object x references being changed without being
changed
elsewhere.
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)
y=43 (y.object_id=87)
x.succ! (x.object_id=0x2389f0d0) a clone of 42 is created and
modifed
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
anyway.
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.ā
Absolutely
And finally: I have absolutely no objection if you want to post my
original
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
taking
all this timeā¦
Cheers
Robert
I much prefer having people have to learn that thatās how