Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34902
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.136.129 cause and error)
Message-ID: <005001c85e23$6a1ed150$c6fc1f3e@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Rasmus Lerdorf" <rasmus@lerdorf.com>,
	"Chris Stockton" <chrisstocktonaz@gmail.com>
Cc: "php-dev" <internals@lists.php.net>
References: <4794AE48.20005@daylessday.org>	 <38791.98.193.37.55.1201055548.squirrel@www.l-i-e.com> <e2e02fe0801231114vb4c7a15r6d037867972ad4e5@mail.gmail.com> <47979570.4010703@lerdorf.com>
Date: Thu, 24 Jan 2008 00:52:34 -0000
Organization: Zend Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
From: steph@zend.com ("Steph Fox")

Blimey. I agree with Rasmus. That's twice now!

I think PHP 6 should be an interim period with support for both scenarios, 
but with the default being bog-standard as-we-know-it IS_STRING and anything 
IS_UNICODE needing to be marked.

Perhaps PHP 7 can drop the IS_STRING stuff and have it all IS_UNICODE, by 
removing the need to mark unicode text and taking it all that way. I think 
doing this in PHP 6 will make for a white elephant situation (and we like 
purple-blue, no?)

- Steph

----- Original Message ----- 
From: "Rasmus Lerdorf" <rasmus@lerdorf.com>
To: "Chris Stockton" <chrisstocktonaz@gmail.com>
Cc: "php-dev" <internals@lists.php.net>
Sent: Wednesday, January 23, 2008 7:28 PM
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP


>I don't disagree with this, and that is actually why I insisted on having 
>the unicode-semantics switch from the early days of the Unicode 
>discussions, so you can blame me, again, if you consider it a bad design 
>decision.
>
> My take on it was that just about all ISPs would run with Unicode 
> semantics off and that the Unicode semantics on mode was more geared for 
> large standalone applications and sites that wanted the luxury of working 
> natively in their chosen character set without needing to always jump 
> through hoops.
>
> If we get rid of the switch, then I agree that we can't make the default 
> string IS_UNICODE.  We would be crippling the implementation and taking a 
> step backwards in terms of leading the way in Unicode adoption.  The 
> longterm goal for just about everyone has got to be a "Unicode everywhere" 
> approach.  It used to be that the Web was primarily a Western single-byte 
> charset phenomena, but that hasn't been the case for years.  All major 
> applications out there have implemented various hacks to deal with these 
> issues, some with more success than others.
>
> This is what PHP does.  We take common Web development pains and try to 
> reduce them.  Think back to the pains of XML parsing in PHP 3 and even in 
> PHP 4 compared to today.
>
> Ultimately we need to get to Unicode everywhere, and the Unicode semantics 
> switch was an acknowledgement that the world isn't quite ready for that 
> yet.  But it sounds like the world isn't ready for the switch either. 
> Without it, I am afraid we will never get there, and that may just be 
> something we have to live with.
>
> -Rasmus
>
> Chris Stockton wrote:
>> I partially agree, I have been watching this discussion and it's funny
>> how we have such a class of high end developers saying to break old
>> PHP code. But, the majority of the success of PHP is not due to this
>> small class of high end developers, it's due to it's availability in a
>> shared hosting environment, and the ease of use for beginners, and the
>> oodles of fairly poor quality code that is easy to copy and paste onto
>> peoples websites.
>>
>> Look at the adoption of php4, many webhosts haven't even updated to
>> PHP5 completely due to things like register_globals and small
>> backwards compatibility breakage. The list of problems is small and
>> correctable, if you give system engineers at all of these hosting
>> companies the choice of A. Upgrade to php6 and drive support calls
>> through the roof, or B. Stay at PHP4/5 for eternity until a more
>> (insert your complaints / rants here) language comes along to dethrone
>> PHP.
>>
>> Problem is, PHP has been built to great success based on it's early
>> foundation, but now a group of high class developers want it to be
>> more then PHP was built onto. You will sacrifice it's success if
>> backwards compatibility is not just, broke, but obliterated. Why
>> change PHP's philosophy? Keep it easy for the new user, keep it
>> successful, and make me work a little more when I want to implement my
>> "high class" development methodologies. I don't mind, I do it already.
>>
>> I write this as a "high class" developer.
>>
>> -1
>>
>> -Chris
>>
>> On Jan 22, 2008 7:32 PM, Richard Lynch <ceo@l-i-e.com> wrote:
>>> On Mon, January 21, 2008 8:38 am, Antony Dovgal wrote:
>>>> 6 reasons why we must to get rid of The Switch ASAP
>>>> ----------------------------------------------------
>>> I was +1...
>>>
>>> Until folks started posting that old PHP scripts won't run as-is in
>>> PHP 6?...
>>>
>>> That's just daft...
>>>
>>> When my webhost upgrades to PHP 6, I need all my old scripts to just
>>> keep on chugging away, as much as possible...
>>>
>>> I really think we're stuck with the default "string" being an
>>> old-school binary string, unless you want to lose a LOT of users in a
>>> hurry, or have PHP 5 stick around forever and ever.
>>>
>>> --
>>> Some people have a "gift" link here.
>>> Know what I want?
>>> I want you to buy a CD from some indie artist.
>>> http://cdbaby.com/from/lynch
>>> Yeah, I get a buck. So?
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>