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: David A. Black on 7 Nov 2009 04:39 Hi -- On Sat, 7 Nov 2009, Marnen Laibow-Koser wrote: > Michael W. Ryder wrote: > [...] >> . I much prefer the >> simplicity of Basic and C with for loops that can go either direction. > > That's because you're trying to write C in Ruby. There are far more > idiomatic ways of doing things -- and they *are* clearer, at least in a > Ruby context. > >> As far as going backwards I use it a lot to parse strings of the form >> "city name ST 12345-6789" to City, State, and Zip Code fields. I look >> for the first blank from the end of the string and assume everything >> after it is the Zip Code, I then find the next two non-blank characters >> and assign them to State, and everything else is the City name. > > That's great in a language like C that doesn't have very good string > handling. The Ruby way to do this would be > city, state, zip = string.split(/\s+/) You'd need to take multi-word city names into account, though. So maybe: city, state, zip = /\A(.*)\s+(\S+)\s+(\S+)\Z/.match(str).captures 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: Marnen Laibow-Koser on 7 Nov 2009 10:02 David A. Black wrote: > Hi -- > > On Sat, 7 Nov 2009, Marnen Laibow-Koser wrote: > >>> "city name ST 12345-6789" to City, State, and Zip Code fields. I look >>> for the first blank from the end of the string and assume everything >>> after it is the Zip Code, I then find the next two non-blank characters >>> and assign them to State, and everything else is the City name. >> >> That's great in a language like C that doesn't have very good string >> handling. The Ruby way to do this would be >> city, state, zip = string.split(/\s+/) > > You'd need to take multi-word city names into account, though. So > maybe: > > city, state, zip = /\A(.*)\s+(\S+)\s+(\S+)\Z/.match(str).captures > Quite right. I was trying for simplicity, but that had indeed crossed my mind. > > 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) Best, -- Marnen Laibow-Koser http://www.marnen.org marnen(a)marnen.org -- Posted via http://www.ruby-forum.com/.
From: RichardOnRails on 7 Nov 2009 18:08 On Nov 4, 4:59 pm, Yukihiro Matsumoto <m...(a)ruby-lang.org> wrote: > Hi, > > In message "Re: Ruby doesn't implement x++ for Fixnum's because ???" > on Thu, 5 Nov 2009 04:25:05 +0900, RichardOnRails <RichardDummyMailbox58...(a)USComputerGurus.com> writes: > > |BTW, I'm not advocating x++ for Ruby. I'm just trying to understand > |whether Ruby would literally change 1 to 2 as opposed to change a > |variable that contains 1 to subsequently contain 2. > > There's no way to modify local variables by sending message in Ruby. > > matz. Thanks for your response, Matz. I've got to study David Black's book more thoroughly. Best wishes, Richard
From: Tony Arcieri on 8 Nov 2009 11:48 [Note: parts of this message were removed to make it a legal post.] On Fri, Nov 6, 2009 at 4:30 PM, Seebs <usenet-nospam(a)seebs.net> wrote: > "variables aren't objects" I've seen this mentioned a few times. I think it's something of a gross misstatement of a problem, and a deeper understanding might be able to peel away some of the layers of the debate here. I can't think of a language where "variables are objects". And this isn't the issue. The real issue is Numeric values (i.e. "objects") are immutable. Other types of objects, however, are mutable. "Everything is an object", except some objects are different than others. Advocates of allowing a ++ operator are suggesting that the operator have a dispatch model which alters the local binding when applied to Numeric types. I'm further suggesting it be dispatched like any other operator when applied to non-numeric types. What I really see happening here is that ++ reveals an otherwise difficult-to-see difference in how immutable and mutable objects behave in Ruby. There's no reason Ruby can't have ++, but it would need special case behavior, because the behavior of Numerics is already a special case. Any ugliness surrounding special-case behavior of ++ when implementing it against Numerics stems from this inconsistency in Ruby itself, not the ++ operator. It's not that I doubt the pragmatism of the immutability of Numeric values (on the contrary, I'm developing a language where *all* values are immutable), but this is really the cause of the problem, and the solution (special casing how Numerics respond to ++ by providing alterations to the local binding) causes me no qualms, as it's only a workaround of the separation of immutable/mutable objects that's a fundamental part of Ruby to begin with. -- Tony Arcieri Medioh/Nagravision
From: Rick DeNatale on 8 Nov 2009 12:45
On Sun, Nov 8, 2009 at 11:48 AM, Tony Arcieri <tony(a)medioh.com> wrote: > On Fri, Nov 6, 2009 at 4:30 PM, Seebs <usenet-nospam(a)seebs.net> wrote: > >> "variables aren't objects" > > > I've seen this mentioned a few times. I think it's something of a gross > misstatement of a problem, and a deeper understanding might be able to peel > away some of the layers of the debate here. > > I can't think of a language where "variables are objects". And this isn't > the issue. In C++ a variable can actually hold the state of an object rather than simply a reference to the object. If you think of object as simply meaning what holds the state of what is denoted by a variable, then C variables hold objects, and since a pointer represents state, even pointer's can be considered objects in this degenerate (if you will) form. And that really is the point with the ++ operator, at least if you want it to have the semantics of C/C++. the c/c++ expression b = a++ has the meaning. 1) copy the current contents of the a variable to b 2) increment the contents of the variable a according to the static type of a, e.g. if it's an int or a pointer to a char add 1 to it, if it's a pointer to a (4-byte) int add 4 to it, etc. The original quest in this thread was to do this by defining a ++ method for FixNum (or Integer). As Matz himself has pointed out in this thread, > > There's no way to modify local variables by sending message in Ruby. > > matz. Which is something I've said on this thread before (multiple times IIRC). This has nothing to do with whether or not the object bound to a variable is immutable, it has to do with how ruby variable bindings can and cannot be changed, and that is the whole point. Now, while it's true that Fixnums have a property of being represented by an immediate value rather than a pointer to a 'boxed' value, and this is possible because they are immutable, it doesn't mean that local variables with non-immediate bindings can be rebound inside the invocation of another method. The only way to define b = a++. in Ruby with C/C++ semantics would be to alter the parser to treat such expressions as syntactic sugar, (which was Charle's proposal), much like += is handled now. Let's say this were done, perhaps by the parser treating: b = a++ as if it were b, a = a, a.succ much like it treats a += 1 as if it were a = a + 1 The actual parser changes would need to be sensitive to other cases like foo(b + a++) which would need to compute a + b before incrementing a. One could alter what the increment did, by redefining succ or a particular class, much like redefining + for a given class can alter the value of a + 1 for a particular binding of a. But one could still not move the actual change of binding into a method, any more than you can redefine the '=' part of '+=' -- 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 |