That really comes down to implementation details -- in Smalltalk, name =
(signature), source and parsed representation are indeed internal to the =
method.  Particularly insofar as you can get those by inspecting the =
method objects, which is what the debugger allows us to do.
Questions about what is and what is not 'in' an object ultimately come =
down to implementation details rather than questions of abstraction.  I =
find it useful to have a 'method as object' abstraction that does =
include those things, even if a particular language might not be =
implemented so as to support those details of that abstraction.  You =
appear to differ in perspective/choice of abstraction, and that's mostly =
fine.
But I would challenge the notion that the name of a method, i.e., the =
message, i.e., the signature, is not part of the method.  What else =
could it be?
Now in more general terms, there's nothing inherent to objects that says =
they must be named, or must bind their names as part of their state.  =
But methods, I think, differ here.

regards,
Bill

On Apr 30, 2011, at 2:40 PM, Chad Perrin wrote:

> On Sun, May 01, 2011 at 01:35:05AM +0900, Bill Felton wrote:
>>=20
>> 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...
>=20
> Not really . . .
>=20
> 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.
>=20
> 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:
>=20
>> 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
>=20
> 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.
>=20
> 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
> --=20
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]