Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79113
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.44 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <012701d0074c$ccfe6f40$66fb4dc0$@devtemple.com>
Date: Mon, 24 Nov 2014 08:20:35 +0800
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <65EFC50E-4D50-49ED-AE3B-8C12CB32DC50@gmail.com>
References: <012701d0074c$ccfe6f40$66fb4dc0$@devtemple.com>
To: Bill Salak <bill@devtemple.com>
Subject: Re: [PHP-DEV] enhance fget to accept a callback
From: tjerk.meesters@gmail.com (Tjerk Meesters)

Hi!

> On 24 Nov 2014, at 02:39, Bill Salak <bill@devtemple.com> wrote:
>=20
> Hi list,
>=20
>=20
>=20
> I'm considering writing an RFC to add a 3rd parameter to fgets which =
accepts
> a user defined function. If we had this today we wouldn't need fgetcsv =
with
> the added benefit of fgetcsv style support for data packaging formats =
we
> would otherwise create more 1 off functions for.  For example, if we =
decided
> to support reading json from files in the same manner as our current =
fgetcsv
> functionality today, we would create an fgetjson function.=20
>=20
>=20
>=20
> This change unifies the way in which we support native transliteration =
of
> data packaging formats from files into php data structures through a =
single
> interface. The other major design benefit, from my point of view, is =
the
> unification of userland transliteration functions/libraries with the =
same
> modality as our native support for these types of use cases. I believe =
this
> will ultimately result in more intuitive userland code around this =
type of
> functionality.

The fgets() function has a few behavioural properties that are hard to =
change:
1) it reads until it reaches a newline;
2) it=E2=80=99s expected to return a string.

The above two properties prevent it from being a good candidate for =
reading other formats, such as CSV or JSON which may:
1) span across multiple lines and
2) almost always return something other than a string.

>=20
>=20
>=20
> Before I go any further in formalizing my proposal, I'd like to get =
feedback
> from list members.
>=20
>=20
>=20
> Thanks for your time.
>=20
> Bill Salak
>=20
>=20
>=20
>=20
>=20