[PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

[ignace nyamagana butera]

Hi Kamil Tekiela,

I read your RFC and I understand the intent in improving the current
parse_str function behaviour by introducing a new function to
avoid possible breakage,
However I feel that we are missing a chance to also improve how parse_str
algorithm is currently used, we could or should (?) use this opportunity
to fix some long shortcomings around parse_str.

In no particular order:

parse_str mangled data while it was acceptable before when it could
directly inject PHP variables into the current scope, this
feature is no longer needed and prevents interoperability with other query
parsing algorithms used in other languages. Also since this mangled data
is not well known it comes as a surprise to average PHP developer as the
behaviour feels unexpected see https://3v4l.org/KIJ9V

parse_str assumes that the query separator is always a "&" which reduces
its usage to only parsing query using that particular character. Again this
might be seen as an edge case but no RFC prevents using any other
character. If you where to use another character you are bound to use some
userland code workaround to then feed the "normalized" string to parse_str

parse_str parse the query string using PHP algorithm while there are now
some established parsing algorithm that are languages independant like
https://url.spec.whatwg.org/#interface-urlsearchparams that defines how a
query string should be parsed.

If we were to introduce your function as is, I feel that we will have to
submit yet another RFC and have a language with at least two ways to parse
a string. So maybe instead of a new function what we need is an object with
a better public API ?  thoughts

[PHP-DEV] [RFC] Kill proprietary CSV escaping mechanism

[ignace nyamagana butera]

As a library maintainer  I agree with Stanislav Malyshev . I'm currently
working on a polyfill in League\Csv to enable usage of the empty string
with the escape character. While providing such feature is straightforward
for the insertion part, doing the same for the reading part in quite
complex because of how PHP fgetcsv works.

Removing the escape character from fgetcsv means that any decent library
will have to provide a polyfill to enable correctly reading legacy CSV
produced with the escape character. And quite frankly seeing how broken the
escape character implementation is, it's easier to keep it in PHP codebase
to ease parsing while making sure it is no longer the default.

So while I would prefer to have a PHP9 free of the escape character
mechanism keeping the mechanism via the fgetcsv function for legacy
purposes seems reasonable. Of course, this should be highlighted in the
documentation.

Re: [PHP-DEV] Making stream functions accepting SplFileObject as valid parameter

[ignace nyamagana butera]

Does adding new methods to SplFileObject easier ? It would mean adding a
getMetaData() (to return stream_get_meta_data infos) method and
(append/prepend/remove)Filter methods to add stream filters API.



On Tue, Oct 3, 2017 at 5:21 PM, Sara Golemon  wrote:

> On Tue, Oct 3, 2017 at 9:44 AM, Dan Ackroyd 
> wrote:
> > On 29 September 2017 at 07:46, nyamsprod the funky webmaster
> >  wrote:
> >>
> >> I've been following the resolution of this bug:
> >>
> >> https://bugs.php.net/bug.php?id=44392
> >>
> >> and it seems that there is no safe way to expose the internal
> >> `SplFileObject` filepointer.
> >
> >
> > It seems that people are scared to comment on a streams related
> question...
> >
> Nah, just distr... OOH SHINY!
>
> > I'm not sure that making stream_* functions accept SplFileObject's
> > would be an appropriate way to solve this problem; it's just too much
> > of a hack.
> >
> Implementation wise, about as difficult as you'd imagine.  We have
> php_stream_from_zval() which is a central place which could be made
> smarter, though most (all?) stream related functions have IS_RESOURCE
> checks that'd have to be dealt with, so it still means touching the
> world.
>
> > However, although it's not safe to expose the underlying file handle
> > used by SplFileObject, I think it _might_ be safe to allow the
> > SplFileObject to return a stream that represents the file, but with
> > the necessary php_stream_ops that aren't safe to use replaced with NOP
> > operations, similar to how it is done in the pgsql extension:
> > https://github.com/php/php-src/blob/879126a2cedef5b6e1c1f701ade17c
> a3da9a39ec/ext/pgsql/pgsql.c#L5406-L5409
> >
> I like this approach in the abstract (though I haven't paged in the
> entire problem space yet).  A proxy wrapper provides (possibily
> implemeted on the SplFileObject itself) keeps the scope of the change
> localized to SPL and has little residual hack smell.
>
> -Sara
>