From: Bill Felton <subscriptions@...>
Date: 2011-05-01T03:53:18+09:00
Subject: Re: Is everything object ?

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:
>> 
>> 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.
> 
> -- 
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]