Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72648
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5301C3A2.3060506@sugarcrm.com>
References: <CAEZPtU6ePFu-evVYyknBJa+0M7QZ3f9QvTeu5vvKpnNp_bkbZg@mail.gmail.com>
	<5301C3A2.3060506@sugarcrm.com>
Date: Mon, 17 Feb 2014 09:14:47 +0100
Message-ID: <CAEZPtU7VUAvyT2kdcQk52Nmh_NHJMMBcX7HyVyCmFJk-sD=GCw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] my take on PHP 6, part 2
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Feb 17, 2014 at 9:09 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> https://wiki.php.net/ideas/php6
>
> Here's a bunch of mine:
> - Clean up error reporting (let's decide - do we want exceptions?

Yes, I wanted that as part of cleaning APIs (errors are parts of
APIs), but you are right, it is and should be a topic on its own.

> Warnings? Both?), make errors not so damn expensive and fix @ to be much
> more lean-and-mean than it is now.

Kill it could be an option too. I see the need of @ as a design failure.

> - Figure out named args. I think it's time.

Oh I forgot that one :)

> - Bringing mbstring, various submodules of intl and assorted other
> things under one roof as proper support for everything one needs with
> i18n and l10n (maybe part of "Unicode support")

Yes, I think it is part of the "Unicode" and "i18N/L10N" support too.

> - Cleaning up resources handling so that various scenarios like "I freed
> resource in error handler and now my code segfaults" wouldn't happen.
> - Cleaning up LSP rules for inheritance checks, we still have some weird
> cases lurking there AFAIR

I would rather kill them and relies on objects ;-)

> - Plug serialize/dtor hole, it's really not good that unserializing data
> allows one to mess up with stuff.

That's a detail, ok, an annoying details but I would like to focus on
say top 10 thing we need, things that will require many
discussions/time to design :)


> - Create a robust design for escaping stuff, so it would be clear what
> should be escaped, in which context and which encoding, etc.


Good point, I think the escaping RFC could be a  good starting point.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org