Re: FileHandle (was: Re: Dir.entries have no home)

On Sun, 13 Jan 2002 13:54:16 GMT, Massimiliano Mirra
<[e-mail]> wrote:

>> I might have thought that defining the methods would
>> be more clear, and, not that it's important, more efficient. Am I
>> missing the meaning, or not understanding the goodness of this
>> approach?
>
>Personal preference.  Having to just add one item in a hash rather
>than a whole method definition makes the screen less crowded with
>same-functionality snippets and lets me insert new information by just
>inserting a new key in the same place (the hash), instead of
>redefining three-line screen-wandering method definitions.  This might
>make the program slightly less efficient but will make me quite a bit
>more efficient.

Yes. Another approach I've sometimes used effectively, rather than
computing methods at run time with what always seems to turn out to be
rather arcane code, is to write a separate program that uses arcane
methods to /generate/ clear code. 
>
>And, if I had been a good boy and not so parsimonious of comments, it
>might have made you more efficient as well. :-)

Well, might be. I'm not deeply into comments myself and try to avoid
needing them by making my code /very/ obvious. Sometimes I succeed.

This reminds me of my previous question in the earlier thread.

What I'm still not quite seeing, though it is coming slowly out of the
mist, is what the /idea/ of the FileHandle object is. Part of this is
due to the fact that we haven't had a conversation as you wrote it --
if I paired with you to produce it, we'd be progressing at the same
speed. As it is, you have leapt ahead on your own and now others need
to come up to speed. In a sense, FileHandle needs _selling_ before
people use it.

Its tests don't quite show me how to use it, or when I might want to
use it. And the code doesn't tell me that (nor would it usually do
so).

I'm interested in this as an XP proponent, because XP teams rely
internally on talking all the time. No object like this would likely
just appear on an XP team: it would come into being slowly, motivated
by something that was happening in the code, and the team would all
see it coming to be, and would all be able to suggest ideas about it.

At the end of that process, everyone tends to know enough about the
object to use it and maintain it, at least as much as they have to,
and the process is very effortless.

What happens when that code is passed on to people who were not there
during its creation is a matter of concern for people who are looking
at XP. XP doesn't as yet say much about how to document code that is
being passed on, and when I asked for an overview of your object, it
caused Dave Thomas to smile privately, since one might thinik that an
XPer believes that all the truth is in the code.

If we look at Dave and Andy's Ruby book we see some really good
examples of how objects like FileHandle are best presented: each
object begins with just a few paragraphs saying what it is and how it
relates to other objects. It was those few paragraphs, /motivating/
FileHandle if you will, that I was looking for.

What's perhaps most interesting about that is that you wrote
FileHandle in response to my own question, my own need, and /still/ I
didn't understand how it was intended to fit that need. 

Anyway, it's an interesting object, an interesting implementation
technique, and an interesting problem in  communication.

Good stuff!

Thanks,

Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.