Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71896
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52EAF181.3000907@sugarcrm.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
 <alpine.DEB.2.10.1401302346240.6067@whisky.home.derickrethans.nl> <52EAF181.3000907@sugarcrm.com>
Date: Sat, 1 Feb 2014 06:31:34 +0900
Message-ID: <CAGa2bXbY8kJ9ky18d1POGbKe=dmeH8Ph5dCrhVic5+R0HgR=PA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Derick Rethans <derick@php.net>, Anatol Belski <ab@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>, Matt Ficken <mattficken@php.net>, 
	"Stephen A. Zarkos" <szarkos@php.net>
Content-Type: multipart/alternative; boundary=001a11c3fc824eead504f14ae893
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3fc824eead504f14ae893
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

On Fri, Jan 31, 2014 at 9:42 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrot=
e:

> > Okay, so I've just looked at your attempt to port the MongoDB driver to
> > the "size_t" branch:
> >
> https://github.com/weltling/mongo-php-driver/compare/mongodb:master...mas=
ter
> >
> > And seriously, this one of the biggest mistakes I've seen in a while.
> > Changing APIs so much that basically half of your code needs an update,
> > or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
> > branch =E2=80=94 especially not so late in the game for 5.6!
>
> Yeah, I looked at that patch and also at the diff between what
> replace.php produces and what is the end result, and it kind of worries
> me. Especially the part when you have to manually update all the types
> and how easy it is to miss one. Not sure, if this is solved
> automatically then I might be overreacting but right now it looks like
> I, for example, have been underestimating the amount of code disruption
> this is causing. I think refactoring PHP types and cleaning them up is a
> good idea, but it also means I can't recommend 5.6 adoption to anybody
> for years after the release, after we're sure extensions that were
> disrupted are stable again. And we're not on stellar numbers with 5.5
> adoption now, even given 5.4 to 5.5 supposed to be pretty much smooth
> ride unless you mess with opcodes.
>
> Again, I'm not against the idea of the patch or the implementation, but
> looking at how much work it seems to take for ext author, I'd say it may
> be a good start for PHP 6 branch.


Once code is updated, then it's a matter of including compatibility header
for older PHP, is't it? However, it's requires many line of changes.
Personally,
I don't mind it at all, though.

Although, I would like to see it soon. It may be better to introduce it fro=
m
6 and start 6 branch now. Even if we choose this path, it would be better
provide new type and macro definition to PHP 5.x for 3rd party modules.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3fc824eead504f14ae893--