From: "David A. Black" Date: 2005-10-04T00:22:07+09:00 Subject: Re: C++ equivs in Ruby Hi -- On Mon, 3 Oct 2005, Robert Klemme wrote: > David A. Black wrote: >> Hi -- >> >> On Mon, 3 Oct 2005, Robert Klemme wrote: >> >>> Pascal GUICHARD wrote: >>> >>>> - on pointers, i try to understand (howto implement) datastructures >>>> in which you need to mix values and references/poiters >>> >>> You cannot use values in Ruby directly. There are only references. Think >>> of Ruby as Java without POD's. In practice there are some >>> optimizations for Fixnums, Symbols and some other types but >>> conceptually (i.e. from a usage point of view) you never see values >>> directly. x = nil >>> x = Object.new >>> x = "foo" >>> x = 123 >>> >>> Here "x" is always a reference variable - like every other variable >>> is a reference variable. It's so simple but sometimes difficult to >>> get used to - especially when coming from other programming >>> languages. >> >> I think the "immediate value" status of Fixnums etc. goes beyond just >> being an optimization, though, and has some practical consequences > > Which? Mainly the explanatory thing :-) But also the fact that: a = :sym b = :sym a and b are the same object. I do realize, though, that this is not specifically a matter of immediacy of value, but more of uniqueness and immutability on the part of symbols. I guess I don't have too many concrete ideas about it.... I've just always felt (though I realize you don't) that it's easier to understand the whole immediate/unique/immutable nature of integers, symbols, nil, true, false if one understands it all at the same time. Pretty non-technical, I admit. >> and >> even some explanatory power. In particular, in: >> >> x = 123 >> >> x holds the immediate value 123, rather than a reference to it, > > But this does not make a difference from a usage point of view: for doing x = > x + 1 (or short x += 1) it doesn't make a difference. Right; I said *explanatory* power :-) [...] > Hm... I don't know whether I can follow this argument. *If* there was a ++ > operator in Ruby, it would probably be the equivalent of > > x++ <=> ($_,x=x,x.succ;$_) > ++x <=> (x=x.succ) > > Maybe Matz found this (especially in the first case) a too complex construct > to be hidden by this unary operator. Dunno. But at the moment I fail to see > how this unary operator relates to the fact of "immediate values". Because if x actually *is* a number, then: x = 1 x++ suggests 1++, which makes no sense. It's not that it could not be made to parse as x = x.succ or whatever; it's that (as I understand Matz's reasoning) x++ conventionally suggests an operation on a variable, which obscures the fact that in Ruby, a variable with an integer in it is exactly that integer object. Another way to put it is: assuming that eventually people are going to learn that integers in variables are immediate values, having an overly-sugary x++ would give rise to people asking, "How can you increment an actual integer?" Right now what happens is people ask, "Why can't you do x=1; x++ ?" and then they learn about immediate values :-) David -- David A. Black dblack@wobblini.net