On 01/01/2008, Ovid <[EMAIL PROTECTED]> wrote: > --- 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).
Ah this reminds me. One of these days someone needs to write a robust DD output validator. I tried to convince MJD it would be a great example for HOP parser technology and i think I almost succeeded.... yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
