I am definitely in an RCR mood ;) Well as I was reading the archives and Jim Weirich's guidlines I saw an accepted RCR for Integer#odd? Integer#even? I always define Integer#pred for myself it seems so trivial that I did not bother the list *on purpose* I filed the RCR right away. Sorry for breaking the rule it seemed appropriate. But I was considering a second RCR and this one does by no means allow not to consult the community. I would also like to have Integer#pred! and Integer#succ! doing the "obvious" of course. x = 41 x.succ! => 42 x => 42 What do you think ? Cheers Robert
on 2007-01-19 16:31
on 2007-01-19 16:31
On Jan 12, 2007, at 12:06 PM, Robert Dober wrote: > I always define Integer#pred for myself... What does pred stand for? I must be slow today. I would have used prev for previous. James Edward Gray II
on 2007-09-25 22:29
Gregory Brown wrote: > On 1/12/07, Robert Dober <firstname.lastname@example.org> wrote: > > > x = 41 > > x.succ! => 42 > > x => 42 > > This is probably in the same vein as ++. > > I don't like it because since integers are immediate values in ruby, > that looks messy. How about....x++ ? I know, I know - it's pretty radical, but it's 2007. I think we're ready. Regards, Dan PS - Evan Phoenix did this for Sydney, so it's possible. Evan, got a parse.y patch for us?
on 2007-09-25 22:31
On 1/12/07, Robert Dober <email@example.com> wrote: > x = 41 > x.succ! => 42 > x => 42 This is probably in the same vein as ++. I don't like it because since integers are immediate values in ruby, that looks messy.
on 2007-09-25 22:38
On 1/14/07, Gavin Kistner <firstname.lastname@example.org> 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: > > 1) 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. 2) 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
on 2007-09-25 22:41
On Sat, Jan 13, 2007 at 03:25:06AM +0900, Daniel Berger wrote: > > I don't like it because since integers are immediate values in ruby, > > that looks messy. > > How about....x++ ? > > I know, I know - it's pretty radical, but it's 2007. I think we're > ready. > Maybe x++. I'm pretty sure it can't be a method. consider x.method(:succ!), letting x fall out of scope and then invoking #call on that method. Ruby would have to realize it would need to make a closure (unless we just had no unboxed values).
on 2007-09-25 22:44
Hi -- On Sat, 13 Jan 2007, Daniel Berger wrote: >> I don't like it because since integers are immediate values in ruby, >> that looks messy. > > How about....x++ ? > > I know, I know - it's pretty radical, but it's 2007. I think we're > ready. Even when it's 2007++ integers will still be immutable, immediate values :-) I much prefer having people have to learn that that's how Ruby integers are. David
on 2007-09-25 22:44
On Jan 12, 2007, at 1:04 PM, Martin DeMello wrote: > On 1/13/07, James Edward Gray II <email@example.com> wrote: >> On Jan 12, 2007, at 12:06 PM, Robert Dober wrote: >> >> > I always define Integer#pred for myself... >> >> What does pred stand for? I must be slow today. > > predecessor, by symmetry with successor Duh. Thank you. James Edward Gray II
on 2007-09-25 22:45
Hi -- On Sat, 13 Jan 2007, Phrogz wrote: > that it *could* be added to Ruby without violating the immutable > objects. I don't think that's ever been in doubt (that the parser could be trained to turn x++ into x += 1). But the reason Matz has always given for not considering it appropriate is that in languages where it's used it customarily indicates incrementation, rather than reassignment to a variable. So using it for assignment would potentially be misleading. David
on 2007-09-25 22:45
Hi -- On Sat, 13 Jan 2007, Robert Dober wrote: > to consult the community. > > I would also like to have > Integer#pred! and Integer#succ! doing the "obvious" of course. > > x = 41 > x.succ! => 42 > x => 42 > > What do you think ? I don't consider that obvious at all. Integers are immutable, and variables aren't objects -- so it doesn't fit the model. That's also why Matz has never put x++ in the language. David
on 2007-09-25 22:47
dbl...@wobblini.net wrote: > Even when it's 2007++ integers will still be immutable, immediate > values :-) I much prefer having people have to learn that that's how > Ruby integers are. To be fair, that's a perfectly reasonable argument if ++ were to be a method call. If it's to be programmer convenience for x += 1 (syntax sugar for x=x+1) however, it could also be implemented as syntax sugar. I'm personally perfectly happy without ++, but there are certainly ways that it *could* be added to Ruby without violating the immutable objects.
on 2007-09-25 22:48
On 1/13/07, James Edward Gray II <firstname.lastname@example.org> wrote: > On Jan 12, 2007, at 12:06 PM, Robert Dober wrote: > > > I always define Integer#pred for myself... > > What does pred stand for? I must be slow today. predecessor, by symmetry with successor martin
on 2007-09-25 22:49
Well it does not seem that its was a good idea! I was not aware how that RCR has to be interpreted, I meant something else. David (and Gevin in a private mail I did not understand very well, apologies Gevin) was very right when saying it is not obvious)? x=42 x.object_id => 85 x.succ! x.object_id => 87 and that would be a great mess I guess, Integer#succ! would need to know the binding as someone put it, would violate at least one paradigm of OO design (a method changin the scope of the caller) etc. etc. Funny how innocent it looked. Sorry for having wasted your time. But the good news is I do not feel like RCR anymore ;) Cheers Robert
on 2007-09-25 22:50
Daniel Berger wrote: > How about....x++ ? x++ in languages that implement it (PHP I'm sure of, Java and C++ I'm less sure of) increment x after running the statement. So: # All of the ++s are how it would be in PHP/Java/C++ def printNum x puts x.to_s end x = 42 printNum(x++) #=> 42 printNum(x) #=> 43 x = 42 printNum(x.succ!) #=> 43 printNum(x) #=> 43 ++x increments before passing the variable: printNum(++x) #=> 44 printNum(x) #=> 44 So even if this was implemented, I think x++ would be a bad syntax to x.succ! as other languages have something which looks exactly the same and yet does something different. Dan