Cool :)
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 06, 2007 10:26 PM
> To: Andi Gutmans
> Cc: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] RIP PHP 4?
>
> Andi Gutmans wrote:
> > I'd suggest something close to what Rasmus suggested:
Andi Gutmans wrote:
> I'd suggest something close to what Rasmus suggested:
> a) We make a clear statement on PHP.net that at the end of the year we
> plan to discontinue bug fixes for PHP 4 except for security fixes.
> b) We will discontinue supporting PHP 4 on 8/8/8 (because it sounds good
> and
I'd suggest something close to what Rasmus suggested:
a) We make a clear statement on PHP.net that at the end of the year we
plan to discontinue bug fixes for PHP 4 except for security fixes.
b) We will discontinue supporting PHP 4 on 8/8/8 (because it sounds good
and gives people about a year).
I
Lets not say what i didnt say...did anyone ask for
class a (
class b (
)
)
i believe not.. the point was to keep the same coding standards if i
may say so than classes, interfaces, abstracts, etc. simply for
consistency and normalization..
ps sorry for brackets its from my mobile phone
Do we also log the number of downloads of each PHP version? That would
be interesting to see how much it is downloaded, as there are a lot of
shared hosts that do not update their PHP version at all, I have a
host which is still running php-4.3.4, and doesn't want to upgrade,
and is probably going
One file may contain only one namespace and nothing else.
Several files may have the same namespace.
Dmitry.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
> Sent: Saturday, July 07, 2007 12:12 AM
> To: Dmitry Stogov
> Cc: Stefan Wa
On 6 Jul 2007, at 0832, Derick Rethans wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4
at the
end of this year. That does not mean that we will not fix securi
I was just playing with the idea, I would not like to see core team lying too.
Currently I work with both PHP versions and I had to structure all my
code to be compatible with both versions. As you all know, it's really
difficult to keep things working without any trouble on these
versions.
I am,
namespace A::B
{
class BooYa
{
const C = 'Foo';
}
}
--- Then..
import A::B::BooYa;
echo BooYa::C;
Well, we could have braces but...
That way we can put more than one namespace within a file or such...
That is exactly what I don't want to have, since then you can't see in
t
+1
---
Anton C. Swartz IV
Phoenix Edge Network L.L.C. - *Owner*
PHPLogic Development Services – *Co-Owner*
_Based in Indianapolis, IN_
"The Opposite of war is not Peace it is Creation."
Don't let sin rule your body. After all, your body is bound to die, so
dont obey its desires or let any part
Derick Rethans said:
> Ladies, Gentlemen, Kings and Princesses,
>
> With the nice PHP 5 / PHP 6 unicode semantics thread under
> way I am trying to gauge what people feel about dropping
> support for PHP 4 at the end of this year. That does not mean
> that we will not fix security issues, we ha
Looks close to
http://www.nexen.net/chiffres_cles/phpversion/16987-php_stats_evolution_for_april_2007.php
> Hello Vesselin,
>
> what is the source of your numbers?
>
> Best Regards,
>
> Oliver
>
>
> Vesselin Kenashkov schrieb:
>> -1
>> Because the majority of the installation (somebody two month
On Jul 6, 2007, at 10:32 AM, Derick Rethans wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4
at the
end of this year. That does not mean that we will not fix se
+1
On 6-Jul-07, at 10:32 AM, Derick Rethans wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4
at the
end of this year. That does not mean that we will not fix
Hello Vesselin,
what is the source of your numbers?
Best Regards,
Oliver
Vesselin Kenashkov schrieb:
-1
Because the majority of the installation (somebody two month ago in this
list mentioned that php 5 has just 10% adoption) is still php4 just
makes no
sense to drop the support.
--
PHP
On 7/6/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
PHP itself (without classes) hasn't compile-time constants (and variables).
You can define constants only in run-time using define(). This is the reason
why this proposal don't try to use constants and variables in namespaces. So
ithis approach
+1
Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 06, 2007 6:33 PM
> To: PHP Developers Mailing List
> Subject: [PHP-DEV] RIP PHP 4?
>
>
> Ladies, Gentlemen, Kings and Princesses,
>
> With the nice PHP 5 / PHP 6 unicode semantics thr
PHP itself (without classes) hasn't compile-time constants (and variables).
You can define constants only in run-time using define(). This is the reason
why this proposal don't try to use constants and variables in namespaces. So
ithis approach is absolutely consistent.
BTW you can "import" not on
FWIW this is very much in line with bigwigs like IBM and how they manage
WebSphere releases (not that they are a model citizen but worth noting). I
personally see no problem with this but given how widespread PHP4 use is I'd
recommend maybe pushing the date out 3 more months to the March '08 t
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
Sorry guys,
I've added below the unified and more readable diff.
Frode, about your comment I generally agree, it would be much easier to
implement it differently for Windows as a separate code. In this diff I tried
my best to avoid hurting Unix functionality.
Still comments are welcome.
Tzachi
I've found that to be true also. Lying to people who use your product
will only lead to the downfall of your product. Just set a deadline and
draw the hard line in the sand.
---
Anton C. Swartz IV
Phoenix Edge Network L.L.C. - *Owner*
PHPLogic Development Services – *Co-Owner*
_Based in Indianap
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
>>>
My 2 cents:
Before you guys are making any changes in the maintenance process, I
think the end goal (dropping PHP4 support) can happen a lot smoother
with good communication. You can start today by stating really clear on
www.php.net that PHP4 support is going to be dropped in the future and
On Fri, Jul 06, 2007 at 07:57:15PM +0200, Marco wrote:
> >To me it means in the first place that we can add a canned answer to the
> >bugtracker
> >which would say "PHP4 is not supported anymore, install PHP5" and close
> >all PHP4 only reports.
> >
> >So no bug-fixes, no releases except for ones f
+1
--
CRB
Let me introduce you to my very own DMCA-protected encryption key:
BC 1B 64 4A 8D DE 49 E8 C3 7D CC EE 1A AD EE F5
(compliments of Freedom-to-Tinker http://www.freedom-to-tinker.com/?p=1155)
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
On 04/07/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
Nor variables naither constants.
They are defined in run-time.
This seems to me like a bit of drawback. Would it be possible to add
compile-time constants, then (like const FOO = 1; outside a class)?
Creating a class inside a namespace for c
> I have my arguments. One of them is because you keep mantaining PHP4
> for a long time.
> If you had "found a very dangerous issue in PHP4 that could not be
> resolved without moving to PHP5", I think the adoption would be
> greater. Information is everything and manipulating people's fears is
>
>> --- 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
Have you ever asked yourselves... why? why PHP5's adoption is so bad?
I think we have all asked that very same question and the answer is a mix of
a few standard issues. The hard part has always been deciding how to move it
forward. Without the customers demanding change hosts wont do it, witho
To me it means in the first place that we can add a canned answer to the
bugtracker
which would say "PHP4 is not supported anymore, install PHP5" and close
all PHP4 only reports.
So no bug-fixes, no releases except for ones fixing critical security
problems.
And even that should be ceased either
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year.
+1
Regards
Marco
On 7/6/07, Christopher Jones <[EMAIL PROTECTED]> wrote:
Rasmus Lerdorf wrote:
> I'd be more in favour of a statement that put a final death date on it
> which means no new releases of any sort. We could still say
> security-fixes only by the end of the year and then death by 08/08/08 or
> s
On Fri, 6 Jul 2007, Rasmus Lerdorf wrote:
> Derick Rethans wrote:
> > Ladies, Gentlemen, Kings and Princesses,
> >
> > With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
> > trying to gauge what people feel about dropping support for PHP 4 at the
> > end of this year. That does
+1
I thought you're doing it too late. PHP5 was released in 2004 and
until now the adoption is very slow. If you don't break PHP4 support
and "force" companies to update it to PHP5, the reason for existence
of PHP5 is useless.
Have you ever asked yourselves... why? why PHP5's adoption is so bad?
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.
So why keep supporting PHP 4 then?
Because people still use it. Yes, I know it's circular argument, but I
don't think we should break the circle just yet. I think the best would
be to have phase out plan (which should be officially out - like on
php.net etc. - ASAP) which would give enough ti
I agree (this is why wrote "I see (and understand) both the desire of the
developers and the objective reasons..") and I do not want to start this
topic again. The move is inevitable.
But please take a look what Rasmus said:
"I'm breaking your vote only rule. I don't really understand what
dropp
Rasmus Lerdorf wrote:
> I'd be more in favour of a statement that put a final death date on it
> which means no new releases of any sort. We could still say
> security-fixes only by the end of the year and then death by 08/08/08 or
> something like that.
+1
The final PHP 4 patch date should be
I love this. Let's ship it.
-Andrei
On Jul 5, 2007, at 6:49 AM, Dmitry Stogov wrote:
I think the following example is much better, however I am not sure
it's a
right direction. Namespaces are intended to declare names that can
conflict
with names from other namespaces (including global nam
So why keep supporting PHP 4 then?
Stanislav Malyshev kirjoitti:
I'd be more for dropping all support whatsoever by the end of this
year and focus totally on PHP 5/6. Critical security fixes are another
issue altogether.
We already are focused on 5/6. When the last time on the list was
anyth
Vesselin Kenashkov wrote:
> -1
> Because the majority of the installation (somebody two month ago in this
> list mentioned that php 5 has just 10% adoption) is still php4 just
> makes no sense to drop the support.
This is a very old and tired argument, and pretty much is exactly where
Apache httpd
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
I'd be more for dropping all support whatsoever by the end of this year
and focus totally on PHP 5/6. Critical security fixes are another issue
altogether.
We already are focused on 5/6. When the last time on the list was
anything php 4 discussed that wasn't security fix? Almost all the
discu
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
Nevermind the wording, just as soon as we just put a notice on php.net that the
"end is near, prepare yourselves" the sooner hosting companies, etc. realize the
end is really near.. :)
I'd be more for dropping all support whatsoever by the end of this year and
focus totally on PHP 5/6. Critica
On 7/6/07, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 06.07.2007 19:58, Rasmus Lerdorf wrote:
>> To me it means in the first place that we can add a canned answer to the
>> bugtracker which would say "PHP4 is not supported anymore, install PHP5"
>> and close all PHP4 only reports.
>>
>> So no bu
On 06.07.2007 19:58, Rasmus Lerdorf wrote:
To me it means in the first place that we can add a canned answer to the
bugtracker which would say "PHP4 is not supported anymore, install PHP5"
and close all PHP4 only reports.
So no bug-fixes, no releases except for ones fixing critical security
prob
Antony Dovgal wrote:
> On 06.07.2007 19:07, Rasmus Lerdorf wrote:
>> I'm breaking your vote only rule. I don't really understand what
>> dropping support means if we will still release security fixes. That's
>> the mode we have been in for at least a year, so what would change at
>> the end of th
+1
--
>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 Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix security
-1. We still need to do security fixes, and I think we still need to do
important non
+1
--
Mikko Koppanen
On 7/6/07, Derick Rethans <[EMAIL PROTECTED]> wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean
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
> > > Right. You can have namespace UTF8 and function strlen() in it.
> >
> > This kind of "overriding" would make an interesting feature! However, if
> > a programmer creates - by coincidence - a method with the name of an
> > built-in PHP function, he alters the program's behaviour; from another
On 06.07.2007 19:07, Rasmus Lerdorf wrote:
I'm breaking your vote only rule. I don't really understand what
dropping support means if we will still release security fixes. That's
the mode we have been in for at least a year, so what would change at
the end of the year?
Dropping support to me m
Derick Rethans wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix security
issues, we have to as
Derick Rethans wrote:
> Ladies, Gentlemen, Kings and Princesses,
>
> With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
> trying to gauge what people feel about dropping support for PHP 4 at the
> end of this year. That does not mean that we will not fix security
> issues, we h
+1
On Fri, 2007-07-06 at 16:32 +0200, Derick Rethans wrote:
> Ladies, Gentlemen, Kings and Princesses,
>
> With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
> trying to gauge what people feel about dropping support for PHP 4 at the
> end of this year. That does not mean that w
Derick Rethans wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix security
issues, we have to as
On Fri, 2007-07-06 at 17:51 +0300, Vesselin Kenashkov wrote:
> -1
> Because the majority of the installation (somebody two month ago in this
> list mentioned that php 5 has just 10% adoption) is still php4 just makes no
> sense to drop the support. I see (and understand) both the desire of the
> de
-1
Because the majority of the installation (somebody two month ago in this
list mentioned that php 5 has just 10% adoption) is still php4 just makes no
sense to drop the support. I see (and understand) both the desire of the
developers and the objective reasons for the rush on the new versions, a
Derick Rethans wrote:
> Ladies, Gentlemen, Kings and Princesses,
>
> With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
> trying to gauge what people feel about dropping support for PHP 4 at the
> end of this year. That does not mean that we will not fix security
> issues, we h
Derick Rethans schrieb:
> Your votes please (only -1 and +1 are allowed)!
+1
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
On 06/07/07, Derick Rethans <[EMAIL PROTECTED]> wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix s
+1
Derick Rethans kirjoitti:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix security
issues, we hav
On Fri, Jul 06, 2007 at 04:32:50PM +0200, Derick Rethans wrote:
> Ladies, Gentlemen, Kings and Princesses,
>
> With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
> trying to gauge what people feel about dropping support for PHP 4 at the
> end of this year. That does not mean tha
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
>
+1
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]
Sent: Friday, July 06, 2007 8:33 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] RIP PHP 4?
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to
On 06.07.2007 18:32, Derick Rethans wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix security
i
On 7/6/07, Derick Rethans <[EMAIL PROTECTED]> wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix sec
+1
On 7/6/07, Derick Rethans <[EMAIL PROTECTED]> wrote:
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix
Ladies, Gentlemen, Kings and Princesses,
With the nice PHP 5 / PHP 6 unicode semantics thread under way I am
trying to gauge what people feel about dropping support for PHP 4 at the
end of this year. That does not mean that we will not fix security
issues, we have to as the install base is too
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
On Thu, 5 Jul 2007, William A. Rowe, Jr. wrote:
> Stanislav Malyshev wrote:
> >> something isn't clear to me: Is php as apache module supposed to work
> >> without problems - if compiled as zts - only on apache worker or even
> >> on apache prefork?
> >
> > I think if you manage to compile it tha
99 matches
Mail list logo
