>>>>> "BT" == Ben Tilly <[EMAIL PROTECTED]> writes:
BT> On 5/10/05, Uri Guttman <[EMAIL PROTECTED]> wrote: >> >>>>> "BT" == Ben Tilly <[EMAIL PROTECTED]> writes: BT> [...] BT> Maintainability is more important than optimization. I often use BT> this strategy for maintainance reasons. Going full-cycle, one way BT> to accomplish all of this without changing code is to tie to a BT> filehandle that accumulates data and prints it later. >> >> but what if you don't want to print it but log it or send it to a >> message? what if you want a status sub to be useful in many different >> ways? making it use a handle or printing directly limits your >> flexibility and control. delaying printing until you are ready also >> means you can use write_file which is faster than print as it bypassed >> perlio. BT> With tie you can do all of that. It may involve some hoops, but you BT> can do it. You may need to write your own Tie class though. which is more bother than doing the prints at a higher level. and that can be done in a object/module too so it can be reused. the issue is when do you do the prints, not how. BT> The key point was "without changing code". I should have been BT> more explicit about that. This is a strategy to consider if you BT> have existing code and wish to refactor in a way which is BT> inconsistent with how it was intended to work. I would not BT> normally choose to write new code on that plan. sure, dealing with legacy code makes a big difference. my idea is for new designs (or major rewrites, not just refactoring). BT> As for performance, again I consider optimization less important BT> than maintainability until proven otherwise. Besides, in my BT> experience the bulk of I/O time tends to be spent waiting for BT> resources (another process, filesystems etc) rather than stdio BT> buffering. this is more for flexibility which is part of my forward view of code. the maintainer would have less work to change where stuff is printed if it were in one place and higher up in the logic. code that generate text should return it so the callers can accumulate (and mung in other ways too) until it gets to the code that actually decides where to print it. it may never be printed but sent as a message which would require the text to be accumulated first (you can't print parts of messages in sequence). a caller sub could use the returned text in other ways than just printing. the whole idea is that printing is separated from text generation. it is isolating how you handle the result from how it is generated and that gives you more control and flexibility. this is not a hard and fast rule and i print along the way in many places (such as debug prints, short scripts, etc.). but in a large complex system where text is generated and used in many ways, printing at a low level is a weak design. but we have already beaten this horse enough to have made it win the kentucky derby. :) uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
