--0016e64946d8f9a8900477ded997
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 6, 2009 at 4:30 PM, Seebs <usenet-nospam / 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

--0016e64946d8f9a8900477ded997--