Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30260
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.234 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Vh3kP8oPZ5BWssOgW+P6vkmrp3QZwKF+WmHvZSxeuvmY6fySO3gh2Eg+894xd0sloQG7J+cyCQq/+V15C+bjUxYJpyclT59snymVGdZIVjiMfWBbpQS+bgzCgMlNmlr16e2+NCy4UvOkvQ3WbZhBa+HkyPqHEggEvqdNKFK1jCg=
Message-ID: <fe05d1540706190849h23bc9d3qcb1d12ea4ae9997f@mail.gmail.com>
Date: Tue, 19 Jun 2007 17:49:33 +0200
To: "Rasmus Lerdorf" <rasmus@lerdorf.com>
Cc: internals@lists.php.net
In-Reply-To: <4677F5FB.1070206@lerdorf.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1181829227.3478.3.camel@localhost.localdomain>
	 <7d5a202f0706141844l3c75b556hdbecbcd5a43747c9@mail.gmail.com>
	 <4671F184.2020401@lerdorf.com>
	 <6sof73dj69ldpspfc5ukrc58qr9ckbin2b@4ax.com>
	 <4677E7B1.2080305@lerdorf.com>
	 <fe05d1540706190808o1d9305b3td74edd6d1c75c97@mail.gmail.com>
	 <4677F5FB.1070206@lerdorf.com>
Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6?
From: pierre.php@gmail.com (Pierre)

On 6/19/07, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> Pierre wrote:
> > On 6/19/07, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> >
> >> But this is no different from writing code that will work on both PHP 5
> >> and PHP 6.  The only difference is that instead of checking for PHP 5
> >> you will be checking for Unicode.  Like I said, we don't want the
> >> Unicode decision to be synonymous with PHP 5 vs. PHP 6 because then the
> >> non-Unicode folks will never get the benefits of the non-Unicode
> >> improvements in PHP 6 and we would be forced to support PHP 5 for a lot
> >> longer.  We really stretch our already thing resources in order to
> >> support multiple branches, so anything we can do to get as many people
> >> as possible onto the same codebase helps us a lot.
> >
> > Just as a last (hopefully) comment, even if nothing seemed to have an
> > influence, no matter how many we are to prefer a unicode only mode (so
> > far only you are in favour of it, maybe Andree too but I don't
> > remember his opinion on this topic :).
>
> Uh, this was agreed upon by everyone involved in the design of the
> Unicode support.  So saying I am the only one is extremely misleading.
> I may be the only one explaining why the decision was reached, but I am
> certainly not the only one in favour of it.

Sorry, I did not know that there was many "externals" people involved
in the unicode design  Who was involved? Almost all "core" developers
I asked are against (anyone having a different view, please step in).

> > The gain we hope to have by keeping a non unicode mode is about having
> > more users moving to PHP6. I would like to know why it will work
> > better than with php5, any thoughts?
>
> By not providing it, we ensure that a large number of people will not
> move to PHP 6.  At least by providing it we give ourselves a chance.  I
> think if we drop it we are basically giving up and we will be
> maintaining 2 code bases for the next 10 years.  Do we really want that?

We maintain three branches since a couple of years, having only two is
a real progress. PHP4's one is dying, it was about time. I can live
with two branches and code base for php-src, I have to maintain three
or more branches in many pecl extensions anyway :)

> > And let forget that maintaining (and develop/implement) these two
> > modes will obviously take more time.
>
> More time than maintaining separate Unicode and non-Unicode code bases
> in difference branches?

Yes, code base is cleaner when the two are in two separate branches,
it is easier to merge too. That's a feeling only, I never timed each
merge or change :)

--Pierre