From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-08-22T22:17:48+09:00
Subject: Re: Static typing ain't so bad, after all...

At the risk of sounding flip, I would give two answers. First, don't
name your methods "foo." There was a criticism upthread of
parameter-names that are nonindicative of their purpose, and that
certainly matters if your methods take more than one parameter. But
even more important (in addition to proper documentation) is to name
your methods well. Method names (ideally) should be verbs, long enough
to indicate what they do as precisely as possible, but short enough
not to offend the eye. Another problem is adding side-effects to
methods after they've been defined and named, when you're modifying
your code later on. When you do this, your method is now misnamed and
will give you less help as you (or someone else) tries to read your
code. In addition, well-named methods generally tend to be smaller,
which is a plus in the Ruby stylebook.

The second (flip) answer to your question is: "it doesn't matter."
Most of the time when duck-typing is working well, there is little
question about the right kind of argument for a method. Especially
since you're writing your documentation as you write your methods.
When there is a mismatch, your unit tests will generally emit an error
that's not hard to diagnose. There are cases when you'll tear your
hair out over a hard-to-find type error, and these cases are the heart
of the argument against dynamic typing, but in practice they are very
few indeed.

Another point of style is to write methods in anticipation that they
will be called with several different types (like Arrays or Strings,
or any of a raft of IO types) and just do the right thing in your
method.


On 8/22/06, Lyle Johnson <lyle.johnson@gmail.com> wrote:
> On 8/22/06, Just Another Victim of the Ambient Morality
> <ihatespam@rogers.com> wrote:
>
> >     Has anyone noticed this?  How do you deal with this issue?
>
> Most of the time I'm able to deduce what kind of object the method is
> expecting, but I agree that sometimes I have to do a lot of detective
> work to find out how to use the code.
>
> If an object is passed in to a method, and is *only* used within that
> method, it's usually straightforward to just use the duck typing
> assumption: I just need to pass in some object that's capable of
> responding to the messages that will be sent to it in this context.
>
> But what if the object is passed down into some other method as an
> argument? Or stored in an instance variable for later use? In those
> situations, I have to chase that rabbit all around the code, seeing
> how it's used elsewhere, before I can know for sure what kind of
> object I need to provide.
>
> It's definitely a documentation issue, in my book. But I'm looking
> forward to other responses.
>
>