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 8 Nov 2009 13:01 On 2009-11-08, Tony Arcieri <tony(a)medioh.com> wrote: > I can't think of a language where "variables are objects". I'd say they are in C. In C: { int x; } x is an object. There is storage which is reserved for x, which is not associated with any other object, etcetera. Modifications "to x" always affect this specific object; you can't make x be some other object, all you can do is change its contents. > 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. I think it is the issue though. The reason you can write "x = x + 1" in Ruby, but not "x++", is that you have to modify the variable, not the object. If x was previously the Fixnum 1, you don't want to change 1 to 2 -- you want to change x to point to a different object. You can't do that by sending x a message, though, you have to write it in the code that knows about the variable x. > Advocates of allowing a ++ operator are suggesting that the operator have a > dispatch model which alters the local binding when applied to Numeric > types. (1+2)++ 1+2 => the Fixnum 3 What is the local binding which gets incremented? There's no variable there, only an object. > 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. I don't entirely agree. The difference is most *obvious* with Numerics, but it's true of just about anything. Imagine that we define ++ on an array as equivalent to "a = a + [ nil ]". That is, it appends a new value on the end of the array. Now try setting up an array: a = Array.new b = a a++ How many items does b have? Why, it now has an item, because there is only one array. a and b are not arrays; a and b are variables which hold references to a single array object. What that means is that, while Numerics have special case behavior, *the special case behavior is the one we actually want*. Ignore the return value for a moment. Clearly, the *intent* of "a++" is the same as the *intent* of "a = a + 1". But in Ruby, those aren't the same thing. a = Array.new b = a a = a + [ nil ] This makes a and b into two separate objects. > 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. I disagree, because I think it would violate POLS to have ++ work differently on numerics, when clearly, that behavior (alters local binding) is exactly what we want... Probably. Again, I really think the root of this is that ++ is designed for a language in which the variable is its own object, not a reference to another object. -s -- 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: Seebs on 8 Nov 2009 13:06 On 2009-11-08, Rick DeNatale <rick.denatale(a)gmail.com> wrote: > 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. Insofar as anything in C is "an object", pointers are. -s -- 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 8 Nov 2009 13:18 [Note: parts of this message were removed to make it a legal post.] On Sun, Nov 8, 2009 at 10:45 AM, Rick DeNatale <rick.denatale(a)gmail.com>wrote: > 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. > You still seem to be missing what I'm proposing. For Numerics, ++ would rebind. For everything else, it would be dispatched as a message. Am I being unclear? -- Tony Arcieri Medioh/Nagravision
From: Marnen Laibow-Koser on 8 Nov 2009 13:22 Tony Arcieri wrote: > On Sun, Nov 8, 2009 at 10:45 AM, Rick DeNatale > <rick.denatale(a)gmail.com>wrote: > >> variable is immutable, it has to do with how ruby variable bindings >> can and cannot be changed, and that is the whole point. >> > > You still seem to be missing what I'm proposing. > > For Numerics, ++ would rebind. For everything else, it would be > dispatched > as a message. Yuuuuuuuck! Why do this ugly special-casing for something that's hardly ever needed anyway? > > Am I being unclear? No, just silly. :D Best, -- Marnen Laibow-Koser http://www.marnen.org marnen(a)marnen.org -- Posted via http://www.ruby-forum.com/.
From: Tony Arcieri on 8 Nov 2009 13:25
[Note: parts of this message were removed to make it a legal post.] On Sun, Nov 8, 2009 at 11:22 AM, Marnen Laibow-Koser <marnen(a)marnen.org>wrote: > Yuuuuuuuck! Why do this ugly special-casing for something that's hardly > ever needed anyway? > To reiterate from my previous message, because the behavior of Numerics is already a special case to begin with. -- Tony Arcieri Medioh/Nagravision |