Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72984
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender)
Message-ID: <5318E1C5.1000103@sugarcrm.com>
Date: Thu, 06 Mar 2014 12:59:49 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>, 
 Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Julien Pauli <jpauli@php.net>, 
 PHP Internals <internals@lists.php.net>
References: <CAMUwpuRkkaPHoFabtKA1ypfK6T_mDkGwtbMM3GRFaJPQBVDK3A@mail.gmail.com> <53176168.50305@lerdorf.com> <CAEZPtU5imvkn_Y=bhnW3S+mdeE+Bmku_YgaJ9u_32cQ4P1eKdQ@mail.gmail.com>
In-Reply-To: <CAEZPtU5imvkn_Y=bhnW3S+mdeE+Bmku_YgaJ9u_32cQ4P1eKdQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP6 thoughts about Engine changes
From: smalyshev@sugarcrm.com (Stas Malyshev)

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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227