Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103538
To: Stanislav Malyshev <smalyshev@gmail.com>,
 Pierre Joye <pierre.php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <d46e41f8-e483-8425-280e-42cc04f21242@gmx.de>
 <3081944c-4e55-f303-fddd-7f03cff04034@gmail.com>
 <CAEZPtU6A3LdUWcSJi3Y-Co0yhekhTrqkfcUe+EMq2phq2bA1fA@mail.gmail.com>
 <b5397964-263f-8cc0-70c5-e4a58f1ffb2b@gmx.de>
 <a753394e-4003-d26a-0064-021d5eebf716@gmail.com>
Message-ID: <7c71893f-9807-d4b1-99eb-b9ff7652a67c@gmx.de>
Date: Sun, 2 Dec 2018 16:19:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: <a753394e-4003-d26a-0064-021d5eebf716@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Kill proprietary CSV escaping mechanism
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 30.09.2018 at 22:17, Stanislav Malyshev wrote:

>> 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.

I don't think we're doing anyone a favor by introducing even more
inconsistencies between reading and writing CSV.  Also, if we stick with
the legacy CSV reading, we can't simplify the overly complex
implementation.  Therefore, I suggest to only add support for an empty
$escape parameter (PR #3515), and withdraw the RFC to deprecate and
eventually remove the proprietary escaping mechanism.

-- 
Christoph M. Becker