Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
On 6-Sep-06, at 2:28 PM, M. Sokolewicz wrote:
> Ilia Alshanetsky wrote:
>
>> From a technical perspective it makes sense to keep it php.ini
>> only setting or as Sara insists (STARTUP phase only). However,
>> from a user (hosting companies) perspective it adds a fair degree
>> of complexity to their setup, which would probably mean one php6
>> instance will need to run as CGI or FCGI, which will without a
>> doubt affect adoption rates and/or or unicode.semantics being
>> enabled by default on most installs.
>> Personally, I think we'd be better off with a slower adoption
>> rate, but a more robust PHP without added engine/language
>> complexity per- dir unicode.semantics would add.
>> Ilia Alshanetsky
>
> My personal opinion, as humble as it may be, is that it's pure
> bullshit to even give the chance of disabling it. WHY in hell's
> name would you want to give hoster's the choice?
Well, with unicode semantics enabled, many PHP applications that have
not been designed with PHP6+unicode in mind are likely to break. On
the other hand when semantics are off, those applications may work
just fine. The other reason could be that unicode enabled PHP will be
noticeably slower then the one without it, so hosters to conserve
system resources may only enable it for people who actually need the
functionality.
Ilia Alshanetsky
Hi. I think that adding unicode support is a big enough jump to justify some
code breakage. Why not make unicode support a compile-time switch for those few
who may really have good reasons for wanting the old behaviour? Otherwise,
please just build this in so we can avoid all the support questions regarding
"why does X work on one PHP6 server but not another?" The importance of giving
3rd parties a consistent, solid and well-defined foundation they can rely on
when developing and deploying code can't be stressed enough, IMHO.
Thanks, boots
---------------------------------
All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.
