From: Ron Jeffries Date: 2002-01-14T05:48:09+09:00 Subject: Re: FileHandle (was: Re: Dir.entries have no home) On Sun, 13 Jan 2002 13:54:16 GMT, Massimiliano Mirra 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.