From: itsme213 <itsme213@...>
Date: 2005-01-11T04:46:20+09:00
Subject: Re: Immediate values


"Florian Gross" <flgr@ccan.de> wrote in message
news:34frpjF4ba9kjU1@individual.net...
> itsme213 wrote:
> > Fixnums are encoded as 2's complement bit strings (for example).
> >     Thus, '0000' is an encoded _reference_ to the fixnum '0'.
> >     And '0001' is an encoded _reference_ to the fixnum '1'.
>
> I don't quite get this. How is '0000' different from '0' and '0001' from

Very sorry, I mis-typed something crucial. I meant to say:
*References* to Fixnums are encoded as 2's complement bit strings (for
example)
    Thus, the bitstring 0000 is an encoded _reference_ to the fixnum 0
    And 0001 is an encoded _reference_ to the fixnum 1

And Fixnum#+
    takes 2 references to fixnum objects
    manipulates just the references
        implicitly uses information about referenced Fixnum
            encoded in these references
        e.g. that 0001 refers to 1, 0010 refers to 2
    determines that reference 0001 + 0010 = reference 0010
        which, magically, is the reference to fixnum 3
    and returns a _reference_ to fixnum 3.

> > Most references are encoded as in-memory pointers to heap-allocated
storage
> It does not only contain instance variables. There's also information
> like klass, flags, string buffer pointers and more in the internal
> Structs. (And not all Objects store their instance variables in those
> internal Structs, see exivars.)

I agree. And I think it would help to have a uniform term to refer to all
those that are relevant for explaining the _behavior_ of any object.  For
example, I would like to understand object behavior as always conforming to
the following:
When any object x executes method m, it can only access the <local ivars,
array members, hash entries, class reference, ..., and the parameters passed
to the method call, and globals and constants>, and things accessible
through these. There is no other magic in an the behavior of any object. And
imho, it would be nice to have a uniform term for the <.....> above.

> Again, not sure if this is supposed to be an analogy or simplistic view
> of things, but the result of 2+1 is certainly not dictated by instance
> variables and there are no 'special frozen instance variables' in Ruby.

An analogy. To show that underneath some differences in implementation
optimizations, it is all about objects with ... hmmm. hmmm. what should I
call them? Those things that are sometimes "@name" variables, sometimes x[5]
indexed variables, sometimes x[:k], and sometimes the very highly optimized
    2's-comp-0001.next = 2's-comp-0010.
In my mental framework I think of those them as 'slots'.

> And 2+1 can be changed from 3 to 73. After all 2+1 is just calling the
> plus method on 2 with the argument 1. And methods can be changed:
>
> class Fixnum
>    alias :old_plus :+
>
>    def +(other)
>      return 73 if self == 2 and other == 1
>
>      old_plus(other)
>    end
> end
>
> > However, Fixnums can certainly have other mutable 'instance variables';
we
> > just have to handle the internal implementation differently because the
> > objects themselves are not heap allocated, so we need some other means
to
> > get to these 'inst-vars'.
> > class Fixnum
> >     @@foos = {}
> >     def foo; return @@foos[self]; end
> >     def foo=(x); @@foos[self]=x; end
> > end
>
> This are no instance variables, this are class variables.
>
> Why don't just use instance variables directly? (After all Fixnums can
> have instance variables. They are not stored in the Object struct of
> Fixnums, of course, as Fixnums have no Object structs. So where do they
> go? There's a global exivar table for Objects that can not store their
> instance variables in Object structs. They go there. You don't notice
> this, of course, and that's a good thing.)
>
> > irb(main):001:0> 1.instance_variable_set("@chosen_one", true)
> > => true
> > irb(main):002:0> 1.instance_variable_get("@chosen_one")
> > => true
> > irb(main):003:0> 2.instance_variable_get("@chosen_one")
> > => nil

Even better, and I should have used this instead. Then clearly Fixnums are
_not_ immutable in general, since their instance variables (which **happen**
to be stored in a global exivar table for Objects, just as I **happened** to
choose an effectively global class_variable on Fixnums) can be modified.
Instead, just **some** of the information about any Fixnum is immutable
(those things that are dictated by the laws of math, and are encoded in the
e.g.2's complement representation of references to Fixnums).

And when I do your version of 1.instance_variable_set ...
I have set the i-var for **the** fixnum 1; there is NO other fixnum 1
anywhere, no matter how many other variables I have that also refer to
fixnum 1.

If we do nail this down, we can collectively have a consistent way to
describe the state of a collection of Ruby objects at any point in time
(including arrays, hashes, fixnums, symbols, strings, klass, ...) as: a set
of objects with slots that refer to other objects. And the only possible
changes to this state is (a) creation of new objects, and (b) changes to
slots.

But, all this is not necessary unless we want a clean and consistent answers
to some otherwise tricky underlying questions. We can quite happily and
productively code in Ruby without it, and either develop some alternative
consistent underlying explanation or just don't bother. I have no problem
with that either.