Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.178 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <103ccee5476f5c444cf5b9d12969b036.squirrel@webmail.klapt.com>
References: <CAEZPtU6yorwRtoC1zMiEMrvuB_+ijL+UOBNZ-YJHxFGanw+UXg@mail.gmail.com>
	<CABBJUpdqU=EvaZuYyp4=HxaM=uCw5drjxa_u6qqVR1bJSzeyMQ@mail.gmail.com>
	<CAEZPtU6pdCD-_0O3Xg8+YsbtbE4NHGS7q0EAewm8UBBY2B2_uw@mail.gmail.com>
	<CABBJUpdqiSNvqPcVQXyLmuJapphPDsSQDHHY2CJjZ7uinpAx6w@mail.gmail.com>
	<a82346245b54159f2b30061b9f200c39.squirrel@webmail.klapt.com>
	<CAEKnhAH7ctCOc+TcR+znTxhieGocWHXXKrtWH-0-27dsKyh1yQ@mail.gmail.com>
	<CAEZPtU5y6QH50yvNtH_R5GuJCtBwzpFKusQKS1s6sxBBWayUPw@mail.gmail.com>
	<CAEKnhAHLdN26ZayD6bXLWxBdebLhBnHR25QMpS1wqToev7F_+g@mail.gmail.com>
	<CABBJUpdCgbBkG_WCM=reC9opFYWVCQU0CHJ7b7c1c=YYTJ_yjA@mail.gmail.com>
	<CAEKnhAH5PnDhAW1LPGi6T25FA-Js8YkbBpK2HGxR4TktpnJ=tw@mail.gmail.com>
	<23dacb400dab7987ce59ba76826cfddf.squirrel@webmail.klapt.com>
	<CAEKnhAEjDSOOEneD4ZysN+zOSzUYCg35kO-TxED=C8VhNbnBzg@mail.gmail.com>
	<103ccee5476f5c444cf5b9d12969b036.squirrel@webmail.klapt.com>
Date: Wed, 11 Feb 2015 11:56:34 +0000
Message-ID: <CAEKnhAFnVawHOTsFW0wbLME_djEzSq0L_ExYy0jdBzhaHxbmLw@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Xinchen Hui <laruence@php.net>, Pierre Joye <pierre.php@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3bcbcece74b050eceb19b
Subject: Re: [PHP-DEV] new json, push generated file?
From: bukka@php.net (Jakub Zelenka)

--001a11c3bcbcece74b050eceb19b
Content-Type: text/plain; charset=UTF-8

Hi Anatol,

On Tue, Feb 10, 2015 at 3:35 PM, Anatol Belski <anatol.php@belski.net>
wrote:
>
> Maybe it'd be worth it to move one step after another, see what features
> can be implemented and how do they improve? Maybe they'll be so crucial to
> even make a special case that one can say - yeah, don't care about
> flexibility? Not that one would restrict something without having the bare
> reason in the hand.
>
>
I have been thinking about it and think that you have got a point. Let's
wait when the implementation is ready and then we can make a decision if
it's worthy breaking the flexibility. I have got few other things on my
list before that so it will probably take some time to do the changes and
test it...

I would like to push the the bison tab files shortly as the majority of
people in this thread (including me) are for having them in the repo. The
only thing that I would like is to have a specific version in the repo to
prevent big diffs for small changes in the source files. For now I would
like to have there re2c 0.13.6 (thanks for regenerating it back ;) ) and
bison 2.7.1 gen files. I will update Readme at some point as well and add
there that info.

I think that that all compat are types fixes are sort of done so it would
be probably best to do PR for all json changes as it has lots of advantages
(I'm sure that you all know them so I won't name them... :) )

I won't be adding the config.m4 stuff that is in the PR though. I realized
that it would a bit of hack just for json which probably not good. However
I still like the idea of removing re2c and bison dependency for all users
that don't need to change parsers or scanners. That will require more
changes to the build and probably RFC so it's a bit off-topic. I'll see if
I get time to propose something like that in the future.

Cheers

Jakub

--001a11c3bcbcece74b050eceb19b--