On 2009-11-08, Tony Arcieri <tony / 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 / seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!