On Sat, Jun 07, 2008 at 11:44:02AM -0400, Charles Bailey wrote: [ .. Snip .. ] > In a nutshell, then, my thoughts on the current patch: > - The advantages in defaulting to POSIXy semantics don't outweight the > disadvantages of breaking backward compatibility. As Craig points > out, the breakage will be frequent in some environments. > - If we want to make extended semantics available, put them in > syscopy() or cp(), and break the identity on POSIXy systems between > these routines and copy(). I see that as less of a problem than > changing copy() because I think most programmers who chose to use > syscopy() or cp() are indicating their intention to use a particular > functionality. (This is less so for cp(), but I'd guess that most > people who choose this alias wouldn't be all that hurt if it behaved > like cp(1)). > - If the standard is not to break backwards compatibility at all, we > should implement new extensions in File::Copy::Foo, with clear > warnings in the docs that users of these platform-specific packages > should not expect their code to be portable. > > If there's a conensus that one of these alternate solutions is > appropriate and Abigail is too busy to update her change, I'm happy to > supply a patch to DTRT. When I send in the patch, I was fully aware it would break backwards compatability, and I mentioned that in the mail containing the patch. I was surprised the patch went in. I also mentioned not knowing the effects of the patch on non-Unixy environments. As for the intention of File::Copy to replace "system cp $to $from", IMO, it has utterly failed, one of the reasons being it not respecting the permission bits of the origin. In fact, if I inherit code that uses File::Copy, I take my chainsaw, and replace its copy() calls with "system cp". I'm fine with putting the extended semantics in syscopy() or cp() (I prefer the latter, as the name is shorter; OTOH, currently, syscopy() isn't exported from File::Copy on Unix platforms, any code that uses syscopy() and doesn't use a fully qualified name isn't going to work on Unix platforms anyway). I'm also fine with leaving File::Copy not respecting permission bits at all. But then I'd like to see a clear warning in the documentation that File::Copy::copy isn't a replacement for "system cp", but behaves differently. And I'll keep ranting against anyway claiming I should favour File::Copy over "system cp". But I guess we should first have concensus over what to do (if anything). And I won't have time to do work on it until after the YAPC::NA conference. AbigailThread Previous | Thread Next