From: Josh Cheek <josh.cheek@...>
Date: 2009-09-01T07:29:21+09:00
Subject: Re: Private methods’ viability (was: What is the ruby conventions to name private method?)

--000e0cd5f666975e5b047277903d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 31, 2009 at 4:49 PM, Shot (Piotr Szotkowski) <shot@hot.pl>wrote=
:

> Ryan Davis:
>
> > 4) Don't have private methods if you don't need them.
> > 5) You don't need them. No, really.
>
> I=92ll bite. Note: I consider myself a beginner Rubyist and I=92d love to
> hear your (and others=92!) reasons for the above and/or against the below=
. :)
>
> I use private methods when I factor them out of my public methods (once
> the public methods have decent spec coverage). This makes me think
> harder on the (hopefully =96 minimal) public API of my objects and
> prevents me from calling such methods =91in just that single place
> where it would be useful=92; a method=92s either useful to the outside
> world (and should be promoted to public API with individual, descriptive
> spec coverage) or not, period. Using private methods helps me keep
> checks on this.
>
> I also use protected attr_readers so that my objects can tell whether
> they =3D=3D others of the same kind without exposing their instance
> variables to the outside world; an attr_reader on an Array/Hash/Set
> does not guarantee that the given Array/Hash/Set is not modifiable from
> the outside world=B9, hence I=92d rather not expose such instance variabl=
es
> more than necessary.
>
> =B9 It=92s one of the few places where Ruby diverges from the principle
> of least surprise; I can see certain lovely symmetry and simplicity
> in attr_reader working the same for all variables, but I found the name
> a bit misleading when I started to learn Ruby =96 my thoughts were that
> it should either not be called a reader or should return a dup of the
> variable in question=85 (I did get used to this since then, though, and
> realised that other languages=92 generic getters usually do the same.)
>
> =97 Shot
> --
> Born to be mild. [elpanda]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkqcRXAACgkQi/mCfdEo8UpIWwCeNYQ+NZNW895936Gbnwj3btMA
> ylYAnRbvAkMrzP0Ep6SW1y6kl07id7aV
> =3D0fIP
> -----END PGP SIGNATURE-----
>
>
I do the same thing, I use private methods to encapsulate internal logic.
Sure something _could_ be used elsewhere, or for reasons that I haven't
considered, but it pollutes the public namespace, and obfuscates the API.
The outside world doesn't need (or probably want) to be subjected to the
internal logic of my code. Even I, using my own code later, prefer this
approach, because it simplifies use.

Take the Array class as an example, it has 96 private methods, and 85 publi=
c
methods. The public ones are the ones I almost certainly am looking for, ho=
w
burdensome would it be if they made them all public and I had to look at 18=
1
methods, more than half of which are irrelevant, every time I was trying to
find something.

This is the main reason I use private methods. I also use Rails, in which
private vs public is relevant because it affects behaviour. For example, a
public method in a controller will try to render a template after it has
been called.

I have, however, experienced situations where things are irritating as a
result of private methods, for example, in the API for define_method
http://www.ruby-doc.org/core/classes/Module.html#M001654 it says "This bloc=
k
is evaluated using instance_eval, a point that is tricky to demonstrate
because define_method<http://www.ruby-doc.org/core/classes/Module.html#M001=
654>is
private <http://www.ruby-doc.org/core/classes/Module.html#M001641>. (This i=
s
why we resort to the send hack in this example.)" So it can make things
difficult, as well.

--000e0cd5f666975e5b047277903d--