On Mon, 9 Jul 2007 14:48:28 -0700, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> And I think that we shouldn't, since it removes a big incentive for
> people to move to PHP 6.
I would be inclined to agree as well.
>
> Really, we need to get folks to use Unicode natively as much as
> possible. It
Permit me to give my 2 cents on that and share my small bit of experience
with PHP 6.
First of all, I totally agree with you Antony. I'm currently working on
deploying a big codebase in PHP 6 (for those of you who didn't know, I'm the
GSoC student working on refactoring Jaws for PHP 6) and my hea
Andrei Zmievski schrieb:
> As we see now, yes they will be in PHP 6.
:-))
--
>e-novative> - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
PHP Internals - PHP Runtime Deve
On 10.07.2007 01:48, Andrei Zmievski wrote:
And I think that we shouldn't, since it removes a big incentive for
people to move to PHP 6.
I don't really see much sense in forcing people to use PHP6 if we accept the "PHP5 =
PHP6 - Unicode" formula.
They are just different things, period.
Reall
And I think that we shouldn't, since it removes a big incentive for
people to move to PHP 6.
Really, we need to get folks to use Unicode natively as much as
possible. It is the way of the future, and not some "obscure
feature", as some here have suggested. This kind of attitude is
precise
As we see now, yes they will be in PHP 6.
-Andrei
On Jul 6, 2007, at 7:28 AM, Stefan Priebsch wrote:
Pierre schrieb:
Namespace is one _very_ important reason. If we need a "marketing"
I agree. But AFAIK namespaces were not supposed to be in PHP6, at
least
not in PHP 6.0. Is there an offi
Yes, backporting major features from PHP 6 to 5 will slow down PHP 6
adoption, and I'd like to avoid it if possible.
There is a way to run two engines side by side, by the way: in
separate instances of Apache. It's really not that complicated.
-Andrei
On Jul 6, 2007, at 6:13 AM, Stefan Pr
Once again, you're trying to work with bytes inside Unicode strings,
which just does not make sense. What do you propose we do, somehow
automatically detect that you used \x inside a Unicode string and
turn it into a binary one? Or simply allow one to stick any byte
sequence inside what is
On 7/9/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
Anybody who actually NEEDS Unicode ought to be the ones who have to
type a new keyword or something, not the bazillion users who have no
need for Unicode and likely never will...
I wonder whom do you mean here.
I can't remember many non-unico
Unicode code points can be defined with \u, but PHP6 breaks
existing octal and hex escape sequences.
>>
>> I don't understand what this means...
>
> I think I know...
>
> I have code like this, somewhere:
>
> if (preg_match("|[\xF0-\xFF]|", $data)){
> $data = un_microsuck($data);
> }
>
It adds only the Unicode feature that a tiny niche market needs,
because everything else will be back-ported to PHP 5.
I'm not sure assumption that unicode is needed only for "tiny niche
market" is entirely correct.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www
Maybe strings should be UTF-8 until declared otherwise or something,
because this just won't fly...
UTF8 would not help you with bits (since nobody guarantees you incoming
data is valid UTF-8) and it's impossible to do any unicode stuff on
utf-8 - you'd have to convert it to utf-16 and back on
On Fri, July 6, 2007 11:48 am, Antony Dovgal wrote:
> On 06.07.2007 20:44, Stanislav Malyshev wrote:
>>> You don't by a Porsche if you need a taxi, why would you install
>>> PHP6 if
>>> you don't need Unicode?
>>
>> Namespaces ;)
>
> This reason is only valid if we don't backport such things from P
On Fri, July 6, 2007 1:23 am, Stanislav Malyshev wrote:
>> You mean this will break:
>>
>> > $mask = 0xf0;
>> $value = $_POST['foo'] & $mask;
>> ?>
>>
>> because of Unicode?
>
> I'd say it won't do what it did before. Though I'm not sure bit
> operations on unicode make any sense at all... The
In PHP4/5 \xC4 and \x85 are not characters. They are bytes.
They are both. In PHP 5, character and byte is the same. In Unicode,
it's not.
I can't pay such price. You are reducing available coding options and want
Then you can't use Unicode, at least not directly - you would have to
conve
Jochem Maas wrote:
> Lukas Kahwe Smith wrote:
>> Jochem Maas wrote:
>>> Pierre wrote:
On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> There must be a reason to upgrade to a new PHP version (usually
> features, maybe performance increase etc.). But there also must be no
>>>
Lukas Kahwe Smith wrote:
> Jochem Maas wrote:
>> Pierre wrote:
>>> On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
>>>
There must be a reason to upgrade to a new PHP version (usually
features, maybe performance increase etc.). But there also must be no
reason not to upgrade. Bu
>> --- test.php ---
>> > $string1 = "ą";
>> $string2 = "\xC4\x85";
>> var_dump($string1 == $string2)
>
> How you expect one-character string to be equal to two-character string?
In PHP4/5 \xC4 and \x85 are not characters. They are bytes.
>> ą is in utf-8 (latin small letter a with ogonek, latin e
Moreover, we do have such an extension, it's called "mbstring" and you
can use it even in PHP4.
But the point is that it's _just an extension_, hence the Unicode
support is far far from full.
mbstring is very, very far from unicode support. Look at ICU API
description to see how far :)
--
Sta
If Unicode had been an extension (one of those that are part of the
core and cannot be disabled) with its own
classes/exceptions/functions/etc, then everyone would have been happy.
It will be. I.e., most of ICU functionality will be implemented as an
extension - collators, formatters, etc. etc.
--- test.php ---
How you expect one-character string to be equal to two-character string?
ą is in utf-8 (latin small letter a with ogonek, latin extended-a range).
It contains two bytes with 0xC4 0x85 values.
It contains two bytes in the filesystem. It however contains one
character in PHP.
On 06.07.2007 20:44, Stanislav Malyshev wrote:
You don't by a Porsche if you need a taxi, why would you install PHP6 if
you don't need Unicode?
Namespaces ;)
This reason is only valid if we don't backport such things from PHP6 to PHP5
(5.3, 5.5 or whatever it would be), which I think we shou
You don't by a Porsche if you need a taxi, why would you install PHP6 if
you don't need Unicode?
Namespaces ;)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
Johannes Schlüter schrieb:
> http://www.php.net/~derick/meeting-notes.html#name-spaces repalce MArcus
> with Dmitry in the "Conclusion" and check the other thread.
While we edit the document, can we also drop that *if* printed in italics?
;-)
Kind regards,
Stefan
--
>e-novative> - We make IT
On Fri, 2007-07-06 at 16:28 +0200, Stefan Priebsch wrote:
> Pierre schrieb:
> > Namespace is one _very_ important reason. If we need a "marketing"
>
> I agree. But AFAIK namespaces were not supposed to be in PHP6, at least
> not in PHP 6.0. Is there an official position on wether namespaces will
>
Pierre schrieb:
> Namespace is one _very_ important reason. If we need a "marketing"
I agree. But AFAIK namespaces were not supposed to be in PHP6, at least
not in PHP 6.0. Is there an official position on wether namespaces will
be in PHP 6.0?
Kind regards,
Stefan
--
>e-novative> - We make IT
Jochem Maas wrote:
Pierre wrote:
On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
There must be a reason to upgrade to a new PHP version (usually
features, maybe performance increase etc.). But there also must be no
reason not to upgrade. But you all know this, it has been said before.
N
Pierre wrote:
> On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
>
>> There must be a reason to upgrade to a new PHP version (usually
>> features, maybe performance increase etc.). But there also must be no
>> reason not to upgrade. But you all know this, it has been said before.
>
> Namespa
Jani Taskinen wrote:
Antony Dovgal kirjoitti:
On 06.07.2007 14:04, Lukas Kahwe Smith wrote:
To me it boils down how we want to maintain the "fork":
1) PHP5 and PHP6
2) PHP6 unicode off/on (with PHP5 in maintenance mode)
Considering that people will not jump on PHP6 immediately anyways, I
thi
Antony Dovgal kirjoitti:
On 06.07.2007 14:04, Lukas Kahwe Smith wrote:
To me it boils down how we want to maintain the "fork":
1) PHP5 and PHP6
2) PHP6 unicode off/on (with PHP5 in maintenance mode)
Considering that people will not jump on PHP6 immediately anyways, I
think 1) is more realisti
On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
There must be a reason to upgrade to a new PHP version (usually
features, maybe performance increase etc.). But there also must be no
reason not to upgrade. But you all know this, it has been said before.
Namespace is one _very_ important r
Stefan Priebsch wrote:
IMHO backporting a lot of features to PHP4 is a major reasons for the
slow PHP5 adoption. Basically, it seems that everybody who is not using
OOP feels that PHP4 is fine for them.
what was back ported aside from the memory corruption fix, which I am
sure even pushed a fe
IMHO backporting a lot of features to PHP4 is a major reasons for the
slow PHP5 adoption. Basically, it seems that everybody who is not using
OOP feels that PHP4 is fine for them.
I'd say committing to backporting stuff from PHP6 to PHP5 will yield a
similar situation: very slow or no PHP6 adoptio
This is exactly why I started this thread. I'm afraid the setting causes more
trouble than what it tries to solve..
--Jani
Cristian Rodriguez kirjoitti:
On 7/6/07, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
which will just produce way more
problems to hosters and developers of software for
On 06/07/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Richard Quadling wrote:
> So, all the time and effort going into PHP6 is for 1 maybe-used set of
> functionality which also seems to slow down the entire system. I know
> I MUST be missing something here.
yes you are missing the point bo
Richard Quadling wrote:
So, all the time and effort going into PHP6 is for 1 maybe-used set of
functionality which also seems to slow down the entire system. I know
I MUST be missing something here.
yes you are missing the point both Anthony and I made, that if we remove
the unicode switch we
On 06/07/07, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Fri, 6 Jul 2007, Richard Quadling wrote:
> On 06/07/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> > On 06.07.2007 15:32, Richard Quadling wrote:
> > > If Unicode had been an extension (one of those that are part of the
> > > core and can
On Fri, 6 Jul 2007, Richard Quadling wrote:
> On 06/07/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
> > On 06.07.2007 15:32, Richard Quadling wrote:
> > > If Unicode had been an extension (one of those that are part of the
> > > core and cannot be disabled) with its own
> > > classes/exceptions/fu
On 06/07/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 06.07.2007 15:32, Richard Quadling wrote:
> If Unicode had been an extension (one of those that are part of the
> core and cannot be disabled) with its own
> classes/exceptions/functions/etc, then everyone would have been happy.
Moreover,
On 06/07/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 06.07.2007 15:32, Richard Quadling wrote:
> If Unicode had been an extension (one of those that are part of the
> core and cannot be disabled) with its own
> classes/exceptions/functions/etc, then everyone would have been happy.
Moreover,
On 06.07.2007 15:32, Richard Quadling wrote:
If Unicode had been an extension (one of those that are part of the
core and cannot be disabled) with its own
classes/exceptions/functions/etc, then everyone would have been happy.
Moreover, we do have such an extension, it's called "mbstring" and yo
On 06/07/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 06.07.2007 14:04, Lukas Kahwe Smith wrote:
> To me it boils down how we want to maintain the "fork":
>
> 1) PHP5 and PHP6
> 2) PHP6 unicode off/on (with PHP5 in maintenance mode)
>
> Considering that people will not jump on PHP6 immediately
On 06.07.2007 14:04, Lukas Kahwe Smith wrote:
To me it boils down how we want to maintain the "fork":
1) PHP5 and PHP6
2) PHP6 unicode off/on (with PHP5 in maintenance mode)
Considering that people will not jump on PHP6 immediately anyways, I
think 1) is more realistic, if we make best efforts
Rasmus Lerdorf wrote:
So yes, the only real customers for this full Unicode mode in PHP 6 are
going to be the folks that have full control over their servers and
their software which will likely limit it to hosted services and exclude
large PHP software packages that will necessarily need to be
Derick Rethans wrote:
> On Fri, 6 Jul 2007, Cristian Rodriguez wrote:
>
>> On 7/6/07, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
>>> which will just produce way more
>>> problems to hosters and developers of software for "PHP 6".
>>
>> yes :-( .. So if unicode.semantics cannot be set at runtime
On Fri, 6 Jul 2007, Cristian Rodriguez wrote:
> On 7/6/07, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
> > which will just produce way more
> > problems to hosters and developers of software for "PHP 6".
>
>
> yes :-( .. So if unicode.semantics cannot be set at runtime with
> ini_set() or at le
>>> Unicode code points can be defined with \u, but PHP6 breaks existing
>>> octal and hex escape sequences.
>
> I don't understand what this means...
PHP6.0-200707060630
unicode.fallback_encoding => 'utf-8' => 'utf-8'
unicode.filesystem_encoding => no value => no value
unicode.http_input_encodin
On 7/6/07, Johannes Schlüter <[EMAIL PROTECTED]> wrote:
which will just produce way more
problems to hosters and developers of software for "PHP 6".
yes :-( .. So if unicode.semantics cannot be set at runtime with
ini_set() or at least "per-dir" is a complete non-sense to have it,
as the vast
You mean this will break:
because of Unicode?
I'd say it won't do what it did before. Though I'm not sure bit
operations on unicode make any sense at all... The problem here is the
requirement conflict - how PHP can possibly know if $_POST['foo'] is a
bit field or unicode string?
But if
On Thu, 2007-07-05 at 22:47 -0500, Richard Lynch wrote:
> On Fri, June 29, 2007 3:25 am, Alexey Zakhlestin wrote:
> > The thing which I don't understand is: why do people want backward
> > compatibility that much?
>
> Because if you run a webhost with a zillion users, half of whom are
> screaming
Hi Richard,
- Original Message -
From: "Richard Lynch"
Sent: Thursday, July 05, 2007 10:43 PM
> On Fri, June 29, 2007 1:21 am, Tomas Kuliavas wrote:
> >> If unicode semantics are "on" what exactly is borked in PHP 5?
> >
> > In Unicode mode \[0-7]{1,3} and \x[0-9A-Fa-f]{1,2} refer to uni
On Fri, June 29, 2007 3:25 am, Alexey Zakhlestin wrote:
> The thing which I don't understand is: why do people want backward
> compatibility that much?
Because if you run a webhost with a zillion users, half of whom are
screaming for PHP 6, and half of whom are screaming because something
broke, y
On Fri, June 29, 2007 1:21 am, Tomas Kuliavas wrote:
>> If unicode semantics are "on" what exactly is borked in PHP 5?
>
> In Unicode mode \[0-7]{1,3} and \x[0-9A-Fa-f]{1,2} refer to unicode
> code
> points and not to octal or hexadecimal byte values. Fix is not
> backwards
> compatible.
Gak.
You
Yes, unfortunately the end user needs to be aware enough of his
environment to either control the unicode.semantics flag or choose
the right server to run it on. Believe me, we've tried making
unicode.semantics controllable on a per-request basis, and after a
long and hard debate after part
> It sounds like your libraries are definitely oriented towards working
> with binary strings, rather than Unicode strings. So, I am not sure
> why you have unicode.semantics turned on then. If you turn it off,
> you will get backwards compatibility with PHP 5. And if you do that,
> you can still c
It sounds like your libraries are definitely oriented towards working
with binary strings, rather than Unicode strings. So, I am not sure
why you have unicode.semantics turned on then. If you turn it off,
you will get backwards compatibility with PHP 5. And if you do that,
you can still cre
> Call to developers:
> Create new versions of your apps/libraries which use new features of
> language. Make your users interested in upgrading. If users want it,
> hosting-owners will consider upgrades faster. It's all about
> marketing ;)
It also depends on your marketing policy. PHP 5.2.1 req
Hi,
On 6/29/07, Tomas Kuliavas <[EMAIL PROTECTED]> wrote:
For me it means that I have to maintain wrappers for fwrite,
base64_encode, ord, crc32 and all other unicode aware functions. Any
direct PHP string or stream function call can cause compatibility issues
or notices. Any function working w
>> Unicode code points can be defined with \u, but PHP6 breaks existing
>> octal
>> and hex escape sequences.
>
> What do you mean? Doesn't \x20 create U0020 character? Or you mean you'd
> expect it to create just one-byte 0x20? Doesn't binary string do that?
Try higher than 0x7F values.
If I wri
The thing which I don't understand is: why do people want backward
compatibility that much?
For me, PHP6 is the new environment and I don't want to move my
existing solutions there. That just won't be right.
Just like I didn't reuse code written for PHP4 in PHP5 projects.
This is a major version,
Hi,
On 6/29/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> PHP6 is very noisy ("Notice: fwrite(): 13 character unicode buffer
> downcoded for binary stream runtime_encoding", "Warning: base64_encode()
> expects parameter 1 to be strictly a binary string, Unicode string given")
Well, expor
Unicode code points can be defined with \u, but PHP6 breaks existing octal
and hex escape sequences.
What do you mean? Doesn't \x20 create U0020 character? Or you mean you'd
expect it to create just one-byte 0x20? Doesn't binary string do that?
PHP6 is very noisy ("Notice: fwrite(): 13 chara
On 29/06/07, Tomas Kuliavas <[EMAIL PROTECTED]> wrote:
>> It comes down to predicting the future. Whichever way we go, the
>> decision is going to be second-guessed. If we have critical mass for
>> a
>> clean BC break, then I am ok with it. For me personally it would make
>> things a bit easie
>> It comes down to predicting the future. Whichever way we go, the
>> decision is going to be second-guessed. If we have critical mass for
>> a
>> clean BC break, then I am ok with it. For me personally it would make
>> things a bit easier, but I think it would be a long long time before
>> we
On Tue, June 19, 2007 2:44 pm, Rasmus Lerdorf wrote:
> It comes down to predicting the future. Whichever way we go, the
> decision is going to be second-guessed. If we have critical mass for
> a
> clean BC break, then I am ok with it. For me personally it would make
> things a bit easier, but I
> -Original Message-
> From: Jani Taskinen [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 21, 2007 4:31 AM
> To: Andi Gutmans
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] What is the use of "unicode.semantics"
> in PHP 6?
>
> > I co
s
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] What is the use of "unicode.semantics"
> in PHP 6?
>
> I agree totally on giving options. The users have the option
> to either use PHP 5 (non-unicode) or PHP 6 (PHP 5 + unicode)..
>
> So essentially
On Wed, 2007-06-20 at 23:06 -0700, Andi Gutmans wrote:
> I completely disagree. I believe there will be additional value to PHP 6
> which is not only Unicode. Some is already done, some is on the way, and
> some we don't know yet but when the core developer team momentum turns
> to the latest relea
But my guess is that at least 80%+ of
> PHP 6 users will not run in Unicode mode. For many there's just not
> sufficient reason to do so.
>
> Andi
>
> > -----Original Message-
> > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> > Sent: Tuesda
Hi,
On 6/21/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> That's true, and this 90% doesn't care either about php6.
I completely disagree. I believe there will be additional value to PHP 6
which is not only Unicode. Some is already done, some is on the way, and
some we don't know yet but when
;ll just have to
figure something else out.
Night.
Andi
> -Original Message-
> From: Pierre [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 21, 2007 12:13 AM
> To: Andi Gutmans
> Cc: Rasmus Lerdorf; internals@lists.php.net
> Subject: Re: [PHP-DEV] What is the us
Andi Gutmans wrote:
Well the point was just that Pierre enjoys complaining about everyone
else but doesn't deliver what he promised :) (yes I know he doesn't get
paid for it). Andrei and I have talked to him many times and we were
still hoping something's going to move on that front. If not I ass
On 6/21/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
Well the point was just that Pierre enjoys complaining about everyone
else but doesn't deliver what he promised :)
I never complained about something without providing alternatives. You
can add smileys, that's still BS.
(yes I know he doesn'
ng term.
Andi
> -Original Message-
> From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 20, 2007 11:33 PM
> To: Andi Gutmans
> Cc: Pierre; Rasmus Lerdorf; internals@lists.php.net
> Subject: Re: [PHP-DEV] What is the use of "unicode.semanti
Andi Gutmans wrote:
P.S. - Whatever happened to runtime JIT?
I think Dmitry is doing windows stuff and Pierre is busy as well. I
guess either one of them will do it, once they have time. Nobody else
has stepped up to take this on earlier.
Things are also not moving forward in the namespace
See below:
> -Original Message-
> From: Pierre [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 20, 2007 10:41 PM
> To: Andi Gutmans
> Cc: Rasmus Lerdorf; internals@lists.php.net
> Subject: Re: [PHP-DEV] What is the use of "unicode.semantics"
> in PHP 6
Hi Andi,
On 6/21/07, Andi Gutmans <[EMAIL PROTECTED]> wrote:
I very much agree with Rasmus that giving our users the option is
extremely valuable.
Unicode support is useful to some people but I think it's a mistake to
force it down everyone's throat. Forget the fact that it will be
considerably
> No one is going to write code in their own native language and
> distribute it worldwide.
>
> How can you say that "PHP6 Unicode support is not designed for
> international environment"? Have you even tried it?
Ok. International environment.
Do you have strtoupper|strtolower|strcasecmp function
Andi Gutmans wrote:
Some people here said that we weren't successful in keeping BC between
PHP 5 and PHP 4. Whoever said that must not have migrated applications
between the versions. It took very little effort to do so. Most people I
know did it in a matter of hours for sizeable code bases and
re's just not
sufficient reason to do so.
Andi
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 19, 2007 9:05 AM
> To: Jeremy Privett
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] What is the use of "unicode.sema
No one is going to write code in their own native language and
distribute it worldwide.
How can you say that "PHP6 Unicode support is not designed for
international environment"? Have you even tried it?
-Andrei
On Jun 19, 2007, at 9:27 AM, Tomas Kuliavas wrote:
I don't care about Unicode
Derick Rethans wrote:
>
> > Jeremy Privett wrote:
> > I actually don't have a problem with 95% of PHP 6 installations
> > turning off Unicode support and this being the default
> setting for ISP's.
>
> I do, because that will end up in less hosts running with
> real unicode support. They can
>> We are working on different code. You have code with some specific
>> character set and you can control all strings.
>
> Tomas, stop arguing on this. As a library maintainer, I agree with you and
> I don't understand where the
> 'killer feature' is (I heard that Yahoo China asked for it, or is i
Hi all,
I haven't thought about this too much, just came to mind after following
this thread, so ignore any stupidity. :-)
Wanting to preserve BC where possible, and figuring that code to take
advantage of PHP 6's Unicode support will be either new or rewritten... Is
it possible to always have U
On 6/20/07, Derick Rethans <[EMAIL PROTECTED]> wrote:
> (No need to say that php4 support should have been stopped already)
End of the year :)
As I like (love even) the idea, I completely missed any discussion
about this time but your april fool post on your blog/site. It is not
exactly the w
IMHO the big difference between the 4.x to 5.x migration and the one
from 5.x to 6.x is who do the changes benefit. I think Rasmus made a
very true and correct statement, PHP 6, who's main offering (at least
right now) is unicode support is mostly for the 3-4% of the user base
inside large
On Thu, 14 Jun 2007, Johannes Schlüter wrote:
> Hi Jani,
>
> On Thu, 2007-06-14 at 16:53 +0300, Jani Taskinen wrote:
> > During Derick's talk about PHP 6 at PHP Vikinger, I started to wonder
> > what exactly was the reasoning behind adding something like
> > "unicode.semantics" option. Derick did
On Tue, 19 Jun 2007, Rasmus Lerdorf wrote:
> Jeremy Privett wrote:
> > But, let's look at this situation from another angle. What if
> > unicode.semantics becomes the next magic_quotes or safe_mode, and is
> > ALWAYS OFF in 95%+ of PHP installations? All of the work you did to add
> > unicode supp
On Wed, 20 Jun 2007, Pierre wrote:
> On 6/20/07, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> > What I think Ilia said (between the lines) is that basically we're forking
> > PHP.
> >
> > Perhaps we really need to accept the fact that this has already happened..
> > It started with the CPR for PHP_
On Tue, 19 Jun 2007, Tomas Kuliavas wrote:
> It is possible that I am not correct. Writing functions in native language
> is one of key points in Andrei's presentation.
It's not one his key points, it was meant as a joke. And I know because
I've seen him give this presentation close to a dozen t
On 6/20/07, Jani Taskinen <[EMAIL PROTECTED]> wrote:
What I think Ilia said (between the lines) is that basically we're forking PHP.
Perhaps we really need to accept the fact that this has already happened..
It started with the CPR for PHP_4_4 branch and same is now continuing with
the PHP_5_2 b
What I think Ilia said (between the lines) is that basically we're forking PHP.
Perhaps we really need to accept the fact that this has already happened..
It started with the CPR for PHP_4_4 branch and same is now continuing with
the PHP_5_2 branch. If the support for PHP 4 was _officially_ dropp
Rasmus Lerdorf wrote:
Jani Taskinen wrote:
Yesterday's decisions don't necessarily apply today. ;)
(to be "agile")
Fair enough, but it would be nice if the folks involved in the decision,
including yourself would then clearly state their reasoning for making,
I think I've pretty clearly stat
Hi list,
IMHO PHP6 might need more new features to attract developers to migrate
their code / write new code for PHP6. Unicode support is great for those
who need it, but is likely to cause work for those that "just have to
live with it". Nobody likes to so extra work, and it's hard to get
manager
Hi,
I think that PHP6 adoption will obviously come down to exactly how much
slower unicode support will make things. If its a 10% drop, I think we
will probably find ways to smooth out the kinks with some nice tweaks
here and there. If it gets considerably above 10%, then it will be more
tric
Ilia Alshanetsky wrote:
> Sorry to interject, but just a quick slightly off topic note.
>
> In your earlier e-mail you've said that
>
> -
>
> I actually don't have a problem with 95% of PHP 6 installations turning
> off Unicode support and this being the default setting for ISP's
De: Tomas Kuliavas [mailto:[EMAIL PROTECTED]
> We are working on different code. You have code with some specific
> character set and you can control all strings.
Tomas, stop arguing on this. As a library maintainer, I agree with you and I
don't understand where the
'killer feature' is (I heard t
Sorry to interject, but just a quick slightly off topic note.
In your earlier e-mail you've said that
-
I actually don't have a problem with 95% of PHP 6 installations turning
off Unicode support and this being the default setting for ISP's.
Full Unicode support in an applicati
Jani Taskinen wrote:
> Rasmus Lerdorf wrote:
>> 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 fa
Rasmus Lerdorf wrote:
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.
Yesterday's decisio
101 - 200 of 231 matches
Mail list logo
