Hi! > If we cannot eventually get rid of the escaping for CSV reading (note > that I proposed to keep the possibility to use it until PHP *9*), I > don't think that we should remove it for CSV writing either, since that > would make SplFileObject::setCsvControl() and ::getCsvControl() pretty > much confusing. Consequently, it wouldn't make sense to deprecate using
SplFileObject is a bit of a problem since it has single setting for both reading and writing. I'd say it's fine to deprecate using escape there, with the idea that if somebody needs it for reading, they'd ignore the deprecation message, or use fgetcsv. I guess using single set of setting for both read and write is not that great an idea, in retrospect, but we probably can't do too much about it. I think allowing not having an escape and making it the default is a good idea, though mismatch between read and write may be problematic. At least the first part - allowing not having escape - I think should be done and does not need RFC even, but the default change probably does and I think this should be in a major version, since it's a BC break, albeit not a major one. So, I'd do this: 1. Enable no escape char at all ASAP 2. Switch to no escape by default for read & write for PHP 8 3. Deprecate non-empty escape for SplFileObject and fputcsv for PHP 8, leave fgetcsv alone. -- Stas Malyshev [email protected] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
