Is everything object ?

[Bill Felton]

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...

regards,
Bill

I like Chad's explanation.
=20
I'd like to add that by definition, an object is a state and a =

behavior. In the case of a method object, it surely has a behavior, but =
I would question its state.

On samedi 30 avril 2011 at 10:55, Chad Perrin wrote:=20

=20
I like that distinction, the message is :end_upcase, and the method = is
the code that is invoked. But I still think that considering the = method
itself to be a nonobject has no explanatory value (unless maybe = you're
knee deep in C), and requires lots of confusing explanations for it = to
make sense.

=20
Nah. The method is an expression -- often a complex expression = composed
of multiple expressions. The object is what receives the message,
contains the method, and executes the method.
=20
=20

=20
IOW, the model is message passing, and when the message is received, = it
invokes the method. To get the method then, we must tell the
interpreter, that we want the method that would be invoked by this
message, and it returns it to us. I think that explains the = behaviour
quite nicely. Is there a model which involves non object methods, = which
explains something that this does not, and does not involve = completely
invisible complications?

=20
Within Ruby's model, you do not tell the interpreter to return the
method, nor to invoke the method. You tell the object to execute the
method. The object checks to see whether it can and, if so, executes = the
method. If not, it lets you know (noisily). If the method exists, the
method is what returns something to you if you sent a message that
corresponds to that method.
=20
The model is explained quite simply:
=20
1. You send a message to the object.
=20
2. The object executes a corresponding method.
=20
The method is not something with which you ever interact directly, = once
it has been defined. That's kinda the whole *point* of this object
model: you create classes to define objects with methods, then
instantiate those objects. You talk to the objects about what you = want
them to do, and let them do the heavy lifting.
=20
"Object. Do this for me."
=20
"Yes, sir!"
=20
--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org = ]
=20

 

[Bill Felton]

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

=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

=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 ]

 

[Duke Normandin]

Relevant to this, Kent Beck is reputed to have said "I always knew that
one day Smalltalk would replace Java. I just didn't know it would be
called Ruby."

Too bad the replacement process can't be speeded a bit.