--- Eric Wilhelm <[EMAIL PROTECTED]> wrote: > Do you happen to have another example? This one looks to me like > poorly > written code in the test (or are you citing this as code in the > product?)
What??? That's the point! > Either way, it is glaringly bad code. > > a. any call to slurp() doesn't pass a filename -- screams of evil > b. 2-arg form of open -- banned > c. non-lexical filehandles -- banned This is the sort of stuff that tests are designed to catch, but stuff this bad *might* get missed with tight process boundaries. When you're working with teams of programmers (and you do, virtually, if you use CPAN modules), it's not uncommon to find code which makes global state assumptions (package variables, Perl's built-ins, etc.) If you want, I could come up with far more subtle examples of code which demonstrates this, but I suspect we'll have to agree to disagree. This is a real-world problem I've encountered before and will encounter again (such as the time someone was parsing Data::Dumper output without considering that I may have set $Data::Dumper::Indent to a different value than the default). > Perhaps you're trying to address the "code makes global state > assumptions" issue? Well, I think that might be borrowing trouble. I'm not directly trying to address it, but it's a side-benefit and my real-world experience (as opposed to just sitting back and thinking about it), tells me that I gain more than I lose. > Consider e.g. a singleton which is customizable upon creation > (by-design it assumes that only one set of parameters applies from > creation onward.) How could one test variations on that singleton's > parameters with T::A? Read the docs. I explicitly address this issue. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
