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

On Fri, Apr 29, 2011 at 01:09:25PM +0900, Josh Cheek wrote:
> On Thu, Apr 28, 2011 at 10:40 PM, Chad Perrin <code / apotheon.net> wrote:
> >
> > 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.
>
> Can you be more explicit? They are methods, I don't understand what you
> mean.

Non-method operators are not methods -- by definition.


> >
> > It's perfectly "elegant" in terms of a consistent model without
> > mislabeling methods as objects.  Ruby does not seem to "want" me to thi=
nk
> > of methods as objects, else stuff like this would be meaningful
> >
> >    puts.extend Enumerable
> >    puts.class
> >    foo(puts)
>
> Those are meaningful, if you are interested in what the method returns
> (nil). If you are interested in the method, then don't invoke it. Since
> listing the method's name is syntactic sugar for invoking it, then how do
> you get the method? Just ask for it method(:puts).extend(Enumerable)

The object is nil, not the method.  That's my point.  The puts.class call
is not a meaningful treatment of puts as an object; it's just getting the
Nil class and a blank line output side-effect.


> >
> >     puts.extend Enumerable
>
> That, of course works, puts evalutaes to nil, nil is an object and theref=
ore
> has a singleton class, and therefore can be extended.

It doesn't extend puts; puts is not an object.  Trying to think of puts
as an object doesn't work.  It gives surprising results if you actually
expect it to behave as an object in and of itself, thus violating the
"objects and methods" model of Ruby.

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

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

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

iEYEARECAAYFAk27EFgACgkQ9mn/Pj01uKVySwCg8hI11Tjnl0giGHakiaQA8g+R
+NEAoPV1hV9TzbfPaPNazgAyBuQ1MNmh
=mivm
-----END PGP SIGNATURE-----

--azLHFNyN32YCQGCU--

On Fri, Apr 29, 2011 at 01:09:25PM +0900, Josh Cheek wrote:
> On Thu, Apr 28, 2011 at 10:40 PM, Chad Perrin <code / apotheon.net> wrote:
> >
> > 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.
>
> Can you be more explicit? They are methods, I don't understand what you
> mean.

Non-method operators are not methods -- by definition.


> >
> > It's perfectly "elegant" in terms of a consistent model without
> > mislabeling methods as objects.  Ruby does not seem to "want" me to thi=
nk
> > of methods as objects, else stuff like this would be meaningful
> >
> >    puts.extend Enumerable
> >    puts.class
> >    foo(puts)
>
> Those are meaningful, if you are interested in what the method returns
> (nil). If you are interested in the method, then don't invoke it. Since
> listing the method's name is syntactic sugar for invoking it, then how do
> you get the method? Just ask for it method(:puts).extend(Enumerable)

The object is nil, not the method.  That's my point.  The puts.class call
is not a meaningful treatment of puts as an object; it's just getting the
Nil class and a blank line output side-effect.


> >
> >     puts.extend Enumerable
>
> That, of course works, puts evalutaes to nil, nil is an object and theref=
ore
> has a singleton class, and therefore can be extended.

It doesn't extend puts; puts is not an object.  Trying to think of puts
as an object doesn't work.  It gives surprising results if you actually
expect it to behave as an object in and of itself, thus violating the
"objects and methods" model of Ruby.

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

iEYEARECAAYFAk27EFgACgkQ9mn/Pj01uKVySwCg8hI11Tjnl0giGHakiaQA8g+R
+NEAoPV1hV9TzbfPaPNazgAyBuQ1MNmh
=mivm
-----END PGP SIGNATURE-----