Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34916
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain interjinn.com from 66.11.173.122 cause and error)
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Chris Stockton <chrisstocktonaz@gmail.com>,
	php-dev <internals@lists.php.net>
In-Reply-To: <47979570.4010703@lerdorf.com>
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>
Content-Type: text/plain
Organization: InterJinn
Date: Wed, 23 Jan 2008 22:56:47 -0500
Message-ID: <1201147008.7316.128.camel@blobule>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
From: robert@interjinn.com (Robert Cummings)

Is it possible to take a page out of the database engine's handbook and
tie a charset to a namespace like charsets are tied to tables?

namespace myNamespace charset=utf8
{
    ...
}

Then when no charset is defined it defaults to current PHP semantics.
Win-win?

Cheers,
Rob.


On Wed, 2008-01-23 at 11:28 -0800, Rasmus Lerdorf wrote:
> 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
> >>
> >>
> > 
> 
-- 
...........................................................
SwarmBuy.com - http://www.swarmbuy.com

    Leveraging the buying power of the masses!
...........................................................