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

On Sat, Apr 30, 2011 at 04:35:15PM +0900, Josh Cheek wrote:
>=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.

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

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.

The model is explained quite simply:

1. You send a message to the object.

2. The object executes a corresponding method.

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.

"Object.  Do this for me."

"Yes, sir!"

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

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

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

iEYEARECAAYFAk28H+IACgkQ9mn/Pj01uKUHoACgpKlrQUybR0zzSHBOq1HkNAAp
LlQAn1Rqa3uFxU2zEmX1uTA1j50oHssO
=2nuT
-----END PGP SIGNATURE-----

--KsGdsel6WgEHnImy--

On Sat, Apr 30, 2011 at 04:35:15PM +0900, Josh Cheek wrote:
>=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.

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

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.

The model is explained quite simply:

1. You send a message to the object.

2. The object executes a corresponding method.

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.

"Object.  Do this for me."

"Yes, sir!"

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk28H+IACgkQ9mn/Pj01uKUHoACgpKlrQUybR0zzSHBOq1HkNAAp
LlQAn1Rqa3uFxU2zEmX1uTA1j50oHssO
=2nuT
-----END PGP SIGNATURE-----