Ruby doesn't implement x++ for Fixnum's because ???
in [Ruby]
|
Prev: Thread error "undefined method `keys' for nil:NilClass"
Next: Getting version from PE executables
From: Seebs on 4 Nov 2009 11:50 On 2009-11-04, Yukihiro Matsumoto <matz(a)ruby-lang.org> wrote: > In message "Re: Ruby doesn't implement x++ for Fixnum's because ???" > on Wed, 4 Nov 2009 23:31:46 +0900, Marnen Laibow-Koser <marnen(a)marnen.org> writes: >|I believe you are quite wrong. If a destructive function like gsub! can >|be implemented as a method, then I see no reason that +=, |=, or postfix >|++ couldn't be. > Only if you accept the language that can change the value of 1 to 2. > I don't. Hmph. Fortran can change constants, why's Ruby so much less powerful? :) -s p.s.: Thanks much for providing such an enjoyable language. -- Copyright 2009, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Tony Arcieri on 4 Nov 2009 12:11 [Note: parts of this message were removed to make it a legal post.] On Wed, Nov 4, 2009 at 3:55 AM, Gavin Sinclair <gsinclair(a)gmail.com> wrote: > You've got the onus the wrong way around. > > And adding C-like operators based on a partiular assembly language to > any 21st century language, especially a high-level one, just seems > absurd! > > Extra documentation so we can save three characters (a++ instead of a > += 1) in a rare use case? No thanks! > I think you're missing why ++ could be useful, and it's precisely because Ruby is a "21st century language" The ++ operator, far more than just being syntactic sugar for +=1, would allow you to send an "increment" message to any object, which would change its value in place, i.e. def ++ incrementing_logic_goes_here end I could see this as being handy -- Tony Arcieri Medioh/Nagravision
From: Martin DeMello on 4 Nov 2009 12:23 On Wed, Nov 4, 2009 at 10:41 PM, Tony Arcieri <tony(a)medioh.com> wrote: > > The ++ operator, far more than just being syntactic sugar for +=1, would > allow you to send an "increment" message to any object, which would change > its value in place, i.e. And how exactly would you change the value of 1 in place? martin
From: RichardOnRails on 4 Nov 2009 12:59 On Nov 4, 7:14 am, "David A. Black" <dbl...(a)rubypal.com> wrote: > Hi -- > > > > On Wed, 4 Nov 2009, Charles Oliver Nutter wrote: > > Of course I had to jump in here. > > > Yes, a++ and ++a could easily be rewritten by the parser into the > > appropriate increment+set of a and the expression either returns the > > incremented value or the non-incremented value. And I would like to > > see that added. It doesn't fundamentally change the expectations of > > the programmer, and it provides a one-character-shorter version of > > a+=1. There's really no reason it shouldn't be added, because even in > > Java or C, you are *never* modifying arbitrary references to that > > value...you are *always* re-assigning the value a given variable > > points to. > > > This example: > > > a = 1 > > b = a > > a++ > > > Would cause exactly the same results in every language I've worked > > with...b would be 1 and a would be 2. The ++ operator never modifies a > > value, it modifies what value the variable has assigned to it. If it > > were modifying a value, then using ++ to bump a pointer through memory > > offsets would have horrible side effects for anyone else assigned that > > pointer value. > > > I have seen no convincing argument as to why ++ is not supported in Ruby. > > It would, I think, be quite anomalous, since it would be the only case > (that I can think of anyway) of an assignment expression that didn't > look and feel like an assignment expression. > > I'm also not sure what problem it would be solving, other than adding > to the "make <language> users feel at home in Ruby" effect. But I tend > to think that Ruby should move away from, not towards, doing things > for exclusively that reason. > > David > > -- > The Ruby training with D. Black, G. Brown, J.McAnally > Compleat Jan 22-23, 2010, Tampa, FL > Rubyist http://www.thecompleatrubyist.com > > David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com) On Nov 4, 7:14 am, "David A. Black" <dbl...(a)rubypal.com> wrote: > Hi -- > > > > On Wed, 4 Nov 2009, Charles Oliver Nutter wrote: > > Of course I had to jump in here. > > > Yes, a++ and ++a could easily be rewritten by the parser into the > > appropriate increment+set of a and the expression either returns the > > incremented value or the non-incremented value. And I would like to > > see that added. It doesn't fundamentally change the expectations of > > the programmer, and it provides a one-character-shorter version of > > a+=1. There's really no reason it shouldn't be added, because even in > > Java or C, you are *never* modifying arbitrary references to that > > value...you are *always* re-assigning the value a given variable > > points to. > > > This example: > > > a = 1 > > b = a > > a++ > > > Would cause exactly the same results in every language I've worked > > with...b would be 1 and a would be 2. The ++ operator never modifies a > > value, it modifies what value the variable has assigned to it. If it > > were modifying a value, then using ++ to bump a pointer through memory > > offsets would have horrible side effects for anyone else assigned that > > pointer value. > > > I have seen no convincing argument as to why ++ is not supported in Ruby. > > It would, I think, be quite anomalous, since it would be the only case > (that I can think of anyway) of an assignment expression that didn't > look and feel like an assignment expression. > > I'm also not sure what problem it would be solving, other than adding > to the "make <language> users feel at home in Ruby" effect. But I tend > to think that Ruby should move away from, not towards, doing things > for exclusively that reason. > > David Hi David, First, Thank you for The Well-Grounded Rubyist. I study like other pour over scriptures or the Koran. Your topics are well chose, beautifully explicated. And Manning adding typesetting that enhanced the your work. I started this thread because some of your comments on page 54, e.g. "The un-reference ..." were a blemish among your excellent analyses. The fact that Robert Klemme, whom I also respect highly as a Rubyist, agrees with you gives me pause. But nevertheless, I maintain that my corrected post of today refutes such claims as "... any object that's represented as an immediate value is always the same object." Russel & Whitehead dealt with this kind of issue perhaps a century ago when the defined the first Natural Number, 1, as "the set of all sets that are in one-to-one correspondence with the set containing the Null Set." Plato dealt with this in The Parable of the Caves" with the claim that allegedly concrete things were merely reflections of the "real" objects. I'm not clamoring for a Ruby implementation. I only posted my analysis on this issue to get other people's opinions. And I find it hard compose a mistake free exposition, e.g. the last code lines in yesterday evening's post: a = 2**30-1; show (a) => Got 1073741823; class = Fixnum; object_id = 2147483647; v >> 1 = 1073741823 a = 2**30; show (a) => Got 1073741824; class = Bignum; object_id = 22737670; v >> 1 = 11368835 should have read: a = 2**30-1; show (a) => Got 1073741823; class = Fixnum; object_id = 2147483647; v >> 1 = 1073741823 show(a.pp) => Got 1073741824; class = Bignum; object_id = 22738520; v >> 1 = 11369260 # Of course, "v >> 1" is irrelevant here to make the point that "pp" crossed the Fixnum/Bignum boundary smoothly. Bottom line: Please keep up you great work! I appreciate it very much! Best wishes, Richard
From: Tony Arcieri on 4 Nov 2009 13:16
[Note: parts of this message were removed to make it a legal post.] On Wed, Nov 4, 2009 at 10:23 AM, Martin DeMello <martindemello(a)gmail.com>wrote: > And how exactly would you change the value of 1 in place? > You don't. Are you insinuating the behavior of Fixnums isn't already special cased to begin with? -- Tony Arcieri Medioh/Nagravision |