I understand that this is the standard explanation for this sort of
thing but does anyone else feel that it doesn't quite fit? If
Fixnums can have instance variables then doesn't it make more sense
to think of a as containing a reference to the Fixnum object known
as 4?
I'm pretty sure that it is the object ids that are stored in variables
not the associated values. Ruby of course doesn't actually allocate space
for Fixnums but instead encodes the state of the referenced Fixnum in the
object_id itself. It can do this because Fixnum state is completely
encoded by its identity (i.e., its object_id).
I know I'm being pedantic (again) but I'd rather think of assignment
as *always* copying references. It is simpler that way. The
fancy bit-twiddling/implementation issues really come into play
when the variable is dereferenced not when assignment occurs. At least
that is the way I've come to think about it. Does anyone else think about
it that way?
Gary Wright
···
On Dec 31, 2005, at 10:07 PM, Johannes Friestad wrote:
Fixnums and a few other special types (symbols, true/false/nil,
floats?) are assigned as immediate values: Instead of storing a
pointer (or reference) to the value object, the variable stores the
value directly. So in
a=4
'a' does not hold a reference, technically speaking, but rather the
immediate value 4.
This is an implementation issue, and is done for efficiency.
<gwtmp01@mac.com> wrote in message
news:8C1EA245-472B-4C94-9750-064CB61494BA@mac.com...
I know I'm being pedantic (again) but I'd rather think of assignment
as *always* copying references. It is simpler that way. The
fancy bit-twiddling/implementation issues really come into play
when the variable is dereferenced not when assignment occurs. At least
that is the way I've come to think about it. Does anyone else think
about
it that way?
Gary Wright
Some do (including me), but others don't find it useful. e.g. See
You're describing the user model, I was talking about the
implementation. Immediate values are objects for (almost) all
practical purposes, so whether you think of fixnums as references to
immutable singleton objects or as immediate values doesn't make much
difference.
And as you say, it's simpler to use the same model for everything,
which is why many languages go to quite some lengths to hide the
difference.
I tend to think of programming languages (Ruby, C, assembler) as user
intefaces for the computer hardware. That makes 'usability' an
important factor for programming langauges, and supporting simple (but
still powerful) user models for how the language works is one aspect
of usability.
Implementation details are IMO mostly relevant for explaining why
there are two classes for integers (fixnum and bignum) in the first
place, or for that matter why there are 'integers' and 'floats'
instead of simply 'numbers'. In day-to-day programming, they rarely
matter.
jf
···
On 1/1/06, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
On Dec 31, 2005, at 10:07 PM, Johannes Friestad wrote:
> So in
> a=4
> 'a' does not hold a reference, technically speaking, but rather the
> immediate value 4.
I know I'm being pedantic (again) but I'd rather think of assignment
as *always* copying references. It is simpler that way.