Prev: Thread error "undefined method `keys' for nil:NilClass"
Next: Getting version from PE executables
From: Robert Klemme on 4 Nov 2009 05:13 2009/11/4 lith <minilith(a)gmail.com>: >> Yes, a++ and ++a could easily be rewritten by the parser into the >> appropriate increment+set of a and the expression > > Wouldn't it be cool if ruby had macros? No. -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Gavin Sinclair on 4 Nov 2009 05:50 On Nov 4, 5:58 pm, Charles Oliver Nutter <head...(a)headius.com> wrote: > > There's really no reason it shouldn't be added [...] There's no reason it _should_ be added. That's the reason it shouldn't be. > I have seen no convincing argument as to why ++ is not supported in Ruby. 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! -- Gavin Sinclair
From: David A. Black on 4 Nov 2009 07:14 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)
From: Robert Klemme on 4 Nov 2009 07:26 2009/11/4 David A. Black <dblack(a)rubypal.com>: > Hi -- > > On Wed, 4 Nov 2009, Charles Oliver Nutter wrote: >> 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. +2 (Thanks for the well formulated reasoning, David!) Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Rick DeNatale on 4 Nov 2009 09:07
On Wed, Nov 4, 2009 at 1:58 AM, Charles Oliver Nutter <headius(a)headius.com> 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. Certainly it could be implemented in an extension to the language as syntactic sugar much as += and it's family. But I maintain, that it can't be implemented as a method, any more than += or ||= could be. If Matz deigned to do such a language change, I'd certainly feel free to ignore it. <G> I can't help but think of Alan Perlis' quip that "syntactic sugar causes cancer of the semicolons" -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale |