On 22.01.2008, at 04:14, Andi Gutmans wrote:
I don't think this affects PHP 5.3 (http://wiki.pooteeweet.org/PhP53VoteResult
) which I believe we're making good progress on. It allows us to get
some of those features out earlier including things like namespaces
which the various framework co
2008/1/21, Antony Dovgal <[EMAIL PROTECTED]>:
> 6) we need to remove the switch ASAP
Yes :) I urge you to do this, the introduction of this setting is
probably the worst design mistake in PHP history after safe_mode and
register_globals .
Please withdrawn this insanity before it is too late, if
See below:
> -Original Message-
> From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 21, 2008 8:23 PM
> To: Andi Gutmans
> Cc: Steph Fox; Stas Malyshev; Antony Dovgal; internals@lists.php.net
> Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch
> AS
Without repeating too much of what has already been said, phpBB3 runs
with its own normalizer (NF[CD]K?) and a full implementation of case
folding along with all sorts of other goodies. For us, it would be best
if semantics were off. Then we could trivially determine whether or not
we should us
As for PHP 6 generally: there needs to be a solid migration path,
such as forwards-compatible syntax introduced to PHP 5. MediaWiki
has extensive support for unicode in PHP 5, including a pure PHP
implementation of NFC, cross-script and confusable character
checks, extensive parsing of UTF-
On Jan 21, 2008, at 7:14 PM, Andi Gutmans wrote:
I see I may not have been clear in my previous email.
Indeed as Stas mentioned I agree we should not have a php.ini
switch, i.e. unicode.semantics goes away.
At the same time I propose:
a) We invest considerable energy in figuring out and doc
Antony Dovgal wrote:
6 reasons why we must to get rid of The Switch ASAP
1) it gives users false sense of "compatibility" when no compatibility is even
planned;
2) it's supposed to mean compatibility, but can be changed only in php.ini, which
I see I may not have been clear in my previous email.
Indeed as Stas mentioned I agree we should not have a php.ini switch, i.e.
unicode.semantics goes away.
At the same time I propose:
a) We invest considerable energy in figuring out and documenting the migration
path.
b) We build automated mi
I think the idea was "no php.ini switch, but the question what "foo"
should produce - IS_UNICODE or IS_STRING is still open for consideration".
"foo" alone should produce IS_STRING. The real question IMHO is how far back
do you backport tolerance for a unicode cast.
- Steph
--
PHP Internal
+1, using 'END' as the syntax.
The ~ version to me implies some kind of bit-flipping operation,
whereas the single quotes remind us that interpolation doesn't happen.
--Wez.
On Jan 18, 2008, at 4:07 PM, Stanislav Malyshev wrote:
Hi all!
I remember the topic of 'nowdocs' (if you don't remem
'Unicode strings would be explicit' is one thing, a Unicode mode that
messes up existing code is quite another. So you're looking at keeping
the support dual but changing the userland approach to it, did I hear
you right?
I think the idea was "no php.ini switch, but the question what "foo"
sh
On 1/21/08 2:33 PM, "Antony Dovgal" <[EMAIL PROTECTED]> wrote:
> On 22.01.2008 01:07, Lucas Nealan wrote:
>> There is only one extension with config9.m4, the recode extension and it
>> appears to be using this expressly outside of the context of phpize however
>> it is not problematic to include th
Hi Andi,
As we have discussed in the past the migration path may be extremely hard
moving from PHP 5 to PHP 6. Therefore the community has to come together
and really invest in the migration path more than we have in the past
(like we did from version 2 to 3). This means that during the develo
Hi,
I agree that having such a switch is not going to be a good strategy. The main
reason is the headache application authors are going to have with compatibility
especially when it comes to hosted pre-configured environments and/or dedicated
servers that run more than one application.
I think
Zitat von Antony Dovgal <[EMAIL PROTECTED]>:
6 reasons why we must to get rid of The Switch ASAP
Having maintained a huge Unicode compatible codebase in PHP4 for the
last few years, I know which PITA it already is today, having to
consider the availability of mbstring and iconv, or dealing
Hi Dmitry,
The patch looks fine. Although it wastes a bit more memory than the current
implementation, I think it's ok. It also has some memory fragmentation,
which shouldn't be an issue (we don't have functions with 100 arguments :P).
As a side note, I think the following code could be optim
On 22.01.2008 01:07, Lucas Nealan wrote:
> There is only one extension with config9.m4, the recode extension and it
> appears to be using this expressly outside of the context of phpize however
> it is not problematic to include this. The other four extensions only have a
> config0.m4. Do we prefer
> On 21.01.2008 14:06, Lucas Nealan wrote:
>> I found out the hard way that phpize won't build some extensions like
>> ext/openssl because they have no config.m4, only a config0.m4. I could not
>> find a reason why this shouldn't work and propose the patch below for phpize
>> to support config0.m4
On Mon, 21 Jan 2008, Antony Dovgal wrote:
>
> 6 reasons why we must to get rid of The Switch ASAP
>
Amen!
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 21 Jan 2008, at 19:38, Tomas Kuliavas wrote:
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the worst mistake ever imo - If you wanted PHP 4 you would
simply
use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end
Tomas Kuliavas wrote:
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the worst mistake ever imo - If you wanted PHP 4 you would
simply
use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end user? Onl
Hi,
The attached patch (for PHP_5_3) implements the segmented argument_stack
that has the following advantages:
1) It fixes #43426 and other crashes which occur because of stack
reallocation.
2) The whole stack is never reallocated. So we don't have penalties
because of the while stack cop
5) this is yet another reincarnation of ze1_compatibility switch.
>>> Which is the worst mistake ever imo - If you wanted PHP 4 you would
>>> simply
>>> use PHP 4. Now if you want PHP 5 just damn use PHP 5.
>
>> And if you don't control PHP version used by end user? Only bad in-house
>> apps a
Hello Tomas,
you're point being? Without the requested change here you would have one
more version, resulting in PHP 5.*, PHP 6.*-unicode, PHP6.*-native.
marcus
Monday, January 21, 2008, 6:22:32 PM, you wrote:
>>> 5) this is yet another reincarnation of ze1_compatibility switch.
>> Which is
Tomas Kuliavas schreef:
me, I'm all for dropping unicode.semantics - Antony makes strong points
and it can only help the quality of the product if exceptions and switchable
functionality is kept to a minimum. from a developers POV the same is true,
additionally 'forcing' unicode on the mass
>> 5) this is yet another reincarnation of ze1_compatibility switch.
> Which is the worst mistake ever imo - If you wanted PHP 4 you would simply
> use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end user? Only bad in-house
apps are written for on
Hello Antony,
+1 + thanks, it is simply a ppain in th eass to develop with
7) It alone is responsible for at least 10% slowdown.
marcus
Monday, January 21, 2008, 3:38:00 PM, you wrote:
> 6 reasons why we must to get rid of The Switch ASAP
> ---
> 3) 2+ bigger codebase [1] (with lots of duplicates because we have to
> do
> same things in native and unicode modes);
>
From the cross-reference I assume you mean PHP's codebase. We still
need binary string support — Unicode is only suitable for textual
content. Im
Tomas Kuliavas wrote:
On 21 Jan 2008, at 14:38, Antony Dovgal wrote:
3) 2+ bigger codebase [1] (with lots of duplicates because we have to
do
same things in native and unicode modes);
From the cross-reference I assume you mean PHP's codebase. We still
need binary string support
>> On 21 Jan 2008, at 14:38, Antony Dovgal wrote:
>>> 3) 2+ bigger codebase [1] (with lots of duplicates because we have to
>>> do
>>> same things in native and unicode modes);
>>
>> From the cross-reference I assume you mean PHP's codebase. We still
>> need binary string support — Unicode is only
Forgot to CC list again.
Just not my day.
Original Message
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch
ASAP
Date: Mon, 21 Jan 2008 10:11:32 -0600
From: Jeremy Privett <[EMAIL PROTECTED]>
Organization: Omega Vortex Corporation
To: Geoffrey
Forgot to CC list.
Original Message
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch
ASAP
Date: Mon, 21 Jan 2008 10:07:43 -0600
From: Jeremy Privett <[EMAIL PROTECTED]>
Organization: Omega Vortex Corporation
To: Antony Dovgal <[EMAIL PROTECTED]
On 21 Jan 2008, at 13:24, Hannes Magnusson wrote:
On Jan 18, 2008 10:07 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
Hi all!
I remember the topic of 'nowdocs' (if you don't remember what it is,
read on) was already discussed, but nothing really happened about it.
For those who just recen
On 21 Jan 2008, at 14:38, Antony Dovgal wrote:
2) it's supposed to mean compatibility, but can be changed only in
php.ini, which
means users would still have to maintain 2 versions of their software:
one for On and second for Off.
I think this is the biggest issue for anyone writing softwar
> 6 reasons why we must to get rid of The Switch ASAP
Couldn't agree more!
Regards
Marco
6 reasons why we must to get rid of The Switch ASAP
1) it gives users false sense of "compatibility" when no compatibility is even
planned;
2) it's supposed to mean compatibility, but can be changed only in php.ini,
which
means users would s
On Jan 21, 2008 2:24 PM, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
> > Any objections to this?
>
> No. +1 from me.
+1
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Jan 18, 2008 10:07 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I remember the topic of 'nowdocs' (if you don't remember what it is,
> read on) was already discussed, but nothing really happened about it.
> For those who just recently woke up from cryogenic sleep :), "nowdocs"
On 21.01.2008 14:06, Lucas Nealan wrote:
> I found out the hard way that phpize won't build some extensions like
> ext/openssl because they have no config.m4, only a config0.m4. I could not
> find a reason why this shouldn't work and propose the patch below for phpize
> to support config0.m4 as wel
I found out the hard way that phpize won't build some extensions like
ext/openssl because they have no config.m4, only a config0.m4. I could not
find a reason why this shouldn't work and propose the patch below for phpize
to support config0.m4 as well as config9.m4.
This will generate a standalone
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (65 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
43884 Open Object model
43885
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (629 total including feature requests)
===[*Compile Issues]==
43389 Open configure ignoring --without-cdb flag
===[Apa
42 matches
Mail list logo