On Sun, May 01, 2011 at 01:35:05AM +0900, Bill F. 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 = {:foo => 'foo', :bar => 'bar', :baz => 'baz'}
=> {:foo=>"foo", :bar=>"bar", :baz=>"baz"}
>> bar = foo
=> {:foo=>"foo", :bar=>"bar", :baz=>"baz"}
>> baz = {:foo => 'foo', :bar => 'bar', :baz => 'baz'}
=> {:foo=>"foo", :bar=>"bar", :baz=>"baz"}
>> foo == bar
=> true
>> foo == baz
=> true
>> foo.__id__ == bar.__id__
=> true
>> foo.__id__ == baz.__id__
=> 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.
