Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5318E1C5.1000103@sugarcrm.com>
References: <CAMUwpuRkkaPHoFabtKA1ypfK6T_mDkGwtbMM3GRFaJPQBVDK3A@mail.gmail.com>
	<53176168.50305@lerdorf.com>
	<CAEZPtU5imvkn_Y=bhnW3S+mdeE+Bmku_YgaJ9u_32cQ4P1eKdQ@mail.gmail.com>
	<5318E1C5.1000103@sugarcrm.com>
Date: Fri, 7 Mar 2014 07:26:27 +0100
Message-ID: <CAEZPtU5XRRV+dZa9Ff3DZwx85oF8R+Yf9h6Rk3K2JhEy_Z32Xw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, Julien Pauli <jpauli@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] PHP6 thoughts about Engine changes
From: pierre.php@gmail.com (Pierre Joye)

hi Stas,

On Thu, Mar 6, 2014 at 9:59 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> However you are right. I have the feeling that this list is very
>> optimistic, but a couple of things should be considered (jit f.e.
>> and APIs cleanup for example).
>
> I think if we want the next major happen on reasonable timeframe, we
> should be extremely wary of "rewrite everything" wishlist items,
> especially ones without somebody making very strong commitment at
> actually seeing them through (and note that rewriting API means that
> code depending on the API should be redone too). Whatever is one's
> estimate of how much work would such thing require, it's usually order
> of magnitude or more off, and not to the good side, when you're touching
> deep infrastructure things. So I think we need to separate "pie in the
> sky" items from items that we have an idea where to go with them and
> items that would produce real improvement visible for users. As an
> example, most users wouldn't care much about hooks in the optimizer or
> how exactly source code is parsed, but would care a lot if we got named
> params support or Unicode support. I'm not saying we shouldn't do the
> former, just to separate lists into user and non-user part and be
> realistic about how hard some of these are, and prioritize the user part.
>
> I think if we try to bite off too much we've end up where Unicode effort
> ended - a lot of work ending up in achieving nothing. I think we need to
> have a plan of something that can realistically be done in, say, a year
> or two, and that makes common users (ones that don't care how exactly
> our parsing library is called but have thousands upon thousands of lines
> of code to upgrade and thousands of developers to adopt it) be eager to
> buy into it, something that makes their lives immediately better and
> worth the pain of the upgrade.

Amen :)

-- 
Pierre

@pierrejoye | http://www.libgd.org