From: Chad Perrin <code@...>
Date: 2011-05-01T03:40:07+09:00
Subject: Re: Is everything object ?

--cNdxnHkX5QqsyA0e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, May 01, 2011 at 01:35:05AM +0900, Bill Felton wrote:
>
> Well, you can consider that the state of method includes its name
> (message), its source (the textual representation of the code),
> possibly its compiled representation (especially in JIT or caching
> systems), its comments and its parameters, if any.  Arguable, the
> receiver of a message is also part of a method's state, given that (in
> Smalltalk at least) one can refer to it using 'self'.  Having method
> objects makes powerful debuggers rather easier to construct, at least
> if one wants to stay consistently within a message passing 0-0
> paradigm...

Not really . . .

The message name, source, and parsed representations of a method are not
internal to the method.  Rather, I'd say that the state of an object is
confined to data that you can get out of it via the inspect method
(though I'd entertain arguments that what certain other introspective
methods return might represent an object's "state" as well).  The name of
a message that corresponds to a given method, the source of the method,
and the parsed representation of it are the runtime's state.  On *might*
make a case for some of it being the method's containing object's state
as well.  For instance, the "sort" name could be called a part of the
"['foo','bar','baz']" object, or maybe of the Array class, but not of the
method (code) an Array object executes when it receives the "sort"
message.

The name of an object is not part of the object's state, in my view.  It
is part of Kernel's state, perhaps (I'm not 100% on the relationship
between variable declaration and the Kernel object within which
everything executs, as I understand things); definitely part of the
runtime's state in some way.  It is only a *label* used to refer to the
instantiated object, and not the object itself nor a part of the object.
In fact, these labels (literally) *refer* to the object, and more than
one can do so at the same time:

    > irb --simple-prompt
    >> foo =3D {:foo =3D> 'foo', :bar =3D> 'bar', :baz =3D> 'baz'}
    =3D> {:foo=3D>"foo", :bar=3D>"bar", :baz=3D>"baz"}
    >> bar =3D foo
    =3D> {:foo=3D>"foo", :bar=3D>"bar", :baz=3D>"baz"}
    >> baz =3D {:foo =3D> 'foo', :bar =3D> 'bar', :baz =3D> 'baz'}
    =3D> {:foo=3D>"foo", :bar=3D>"bar", :baz=3D>"baz"}
    >> foo =3D=3D bar
    =3D> true
    >> foo =3D=3D baz
    =3D> true
    >> foo.__id__ =3D=3D bar.__id__
    =3D> true
    >> foo.__id__ =3D=3D baz.__id__
    =3D> false

As you can see, foo, bar, and baz all contain data that evaluates as
equal, but their object IDs are not all the same.  The foo and bar labels
each point to the same object; the baz label points to a different object
that just happens to contain the same hash data.  This is because bar was
assigned as a label for the same object as foo, but baz was constructed
from scratch, and contains a different object.

My point is that "foo" and "bar" and "baz" are not the objects, are not
parts of the objects, and are not included within the objects' state by
the intent of the computational model by which we use the code.  Rather,
they are labels that refer to the objects.  If you subscribe to the
"container" metaphor for variables, you could say that foo contains the
object, but I have long preferred to think of variable names as labels
rather than containers.  After all, it would be pretty difficult for two
containers to contain the same object at the same time without one of
them also containing the other from a three-dimensional perspective, but
it's easy to conceive of slapping more than one label on the same object.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

--cNdxnHkX5QqsyA0e
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk28VE4ACgkQ9mn/Pj01uKW6gwCgn1IFiBVyIAowPw8YcCjcf+M/
YiAAoLIvEg0upEokPCc141tv8Gpe4Z2x
=TbPd
-----END PGP SIGNATURE-----

--cNdxnHkX5QqsyA0e--