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

On Fri, Apr 29, 2011 at 08:39:14AM +0900, Josh Cheek wrote:
> On Thu, Apr 28, 2011 at 3:22 PM, Chad Perrin <code / apotheon.net> wrote:
> >=20
> > Oh, you're talking about boolean operators.  I thought you were talking
> > about actual boolean *methods*:
> >
> >    irb(main):001:0> foo =3D Hash.new
> >    =3D> {}
> >    irb(main):002:0> foo.empty?
> >    =3D> true
>
> I think of operators as methods. Probably the best term for those is
> predicate.

Thinking of them as methods is probably a bad idea.  It may lead you to
make unwarranted assumptions about things you can do with them.


> >
> > . . . but I dispute the argument you present that methods are objects.
> > The fact that one can wrap a method in a "method object" does not make
> > the method *itself* an object; it just creates an object that has a
> > particular kind of interface to the method.
>
> I'm not saying that methods are objects, I'm saying that calling them
> non-objects serves no purpose, and choosing to think of them as objects (=
as
> Ruby obviously wants you to) allows Ruby to be elegant again.

It's perfectly "elegant" in terms of a consistent model without
mislabeling methods as objects.  Ruby does not seem to "want" me to think
of methods as objects, else stuff like this would be meaningful

    puts.extend Enumerable
    puts.class
    foo(puts)

It serves a purpose by helping you keep in mind that methods (techniques
for accomplishing tasks) are not the same as objects (things that "know"
those techniques).

=2E . . but, I guess, if you really want to think of them as objects, I'm
not going to stop you.

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

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAk26L9UACgkQ9mn/Pj01uKWsXwCeO6MXnSJ/VnP0iLV1lWnUzddL
6BQAoO2RYdk+D6qXT/jRT2/DfVjycEn0
=o4qE
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--

On Fri, Apr 29, 2011 at 08:39:14AM +0900, Josh Cheek wrote:
> On Thu, Apr 28, 2011 at 3:22 PM, Chad Perrin <code / apotheon.net> wrote:
> >=20
> > Oh, you're talking about boolean operators.  I thought you were talking
> > about actual boolean *methods*:
> >
> >    irb(main):001:0> foo =3D Hash.new
> >    =3D> {}
> >    irb(main):002:0> foo.empty?
> >    =3D> true
>
> I think of operators as methods. Probably the best term for those is
> predicate.

Thinking of them as methods is probably a bad idea.  It may lead you to
make unwarranted assumptions about things you can do with them.


> >
> > . . . but I dispute the argument you present that methods are objects.
> > The fact that one can wrap a method in a "method object" does not make
> > the method *itself* an object; it just creates an object that has a
> > particular kind of interface to the method.
>
> I'm not saying that methods are objects, I'm saying that calling them
> non-objects serves no purpose, and choosing to think of them as objects (=
as
> Ruby obviously wants you to) allows Ruby to be elegant again.

It's perfectly "elegant" in terms of a consistent model without
mislabeling methods as objects.  Ruby does not seem to "want" me to think
of methods as objects, else stuff like this would be meaningful

    puts.extend Enumerable
    puts.class
    foo(puts)

It serves a purpose by helping you keep in mind that methods (techniques
for accomplishing tasks) are not the same as objects (things that "know"
those techniques).

=2E . . but, I guess, if you really want to think of them as objects, I'm
not going to stop you.

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

iEYEARECAAYFAk26L9UACgkQ9mn/Pj01uKWsXwCeO6MXnSJ/VnP0iLV1lWnUzddL
6BQAoO2RYdk+D6qXT/jRT2/DfVjycEn0
=o4qE
-----END PGP SIGNATURE-----