I am +1 on this idea also.
--Wez.
On 11/14/06, Sara Golemon <[EMAIL PROTECTED]> wrote:
Ilia Alshanetsky wrote:
> -1. Let's not transform 5.2 into a placeholder for PHP6.
>
>
> On 14-Nov-06, at 6:50 AM, Matt Wilmas wrote:
>
>> Hi all,
>>
>>
>> Matt
>> <5_2_binary.txt>
>> --PHP Internals - PHP R
Marcus Boerger wrote:
Hello Richard,
The "#" is needed for CLI mode - thus we won't remove it. In fact we
will not do anything that would cause BC problems. Also there is no
escaping issue with "\". If there is than it is outside of PHP. In
other words:
- "\" is the only single character reachab
Bonsoir,
Antony Dovgal wrote:
Hello all.
I'd like to continue recent IRC discussion here, to draw more attention
to this issue.
At the moment functions fgets() and fgetss() are broken in HEAD, as they
return characters instead of , as they do in 5.2
(and I'm pretty sure this is the way the
It better be in Canadian dollars ;)
(Yeah I got inet access again)
Sara, more seriously, when Zeev puts in a plea and Edin's saying the same
thing, it's likely you're misjudging the situation. It's a rare event :)
On 14-Nov-06, at 3:59 PM, Sara Golemon wrote:
I'll lay money that NOONE is re
On 14-Nov-06, at 3:59 PM, Sara Golemon wrote:
I'll lay money that NOONE is relying on this, and I challenge any
of you to prove me wrong on that count.
Just how much money are we talking about here? ;-)
http://www.google.com/codesearch?as_q=fgets%5C%28%5C%24%5BA-Za-z0-9_%
5D%2B%2C+2%5C%29%3
Marcus,
If it really makes you feel better we can not list the INI parameter in
php.ini and then there's no difference compared to what we have today.
People could find it in the manual.
I really don't see any advantages to that and it's best to improve this
issues asap. People will be sticking to
Hello Andi,
all in all i would actually prefer to have no shebang support in cgi
startin gwith 6 and stick to what we have for 5.x. For Later we have CLI
anyway.
best regards
marcus
Wednesday, November 15, 2006, 12:03:54 AM, you wrote:
> I think in this case it makes very much sense. It will
Ilia Alshanetsky wrote:
> Just because behavior of something had changed in php6 does not mean it
> should change in php5 as well. It is the job of new releases to be
> backwards compatible, not old releases to be forward compatible.
While I agree not to clutter PHP5 too much I can see the point i
I think in this case it makes very much sense. It will allow 99.9% of the
people who don't use shebang for Web apps to gain better performance (less
system calls which is important on highly loaded servers) and allow people
to keep full compatibility if they happen to be odd and use shebang in Web
On 14-Nov-06, at 4:08 PM, Sara Golemon wrote:
I disagree. We're not making 5.2 a placeholder, we're making it a
transitional version.
It is not a transitional version, what gave you this idea? It is a
standalone version, if we decide to make a transitional version we
should create 5.9 b
> why not use a command-line switch for itinstead an INI option?
Because FCGI can't use command-line switches in many situations. And
even if it's allowed it's usually harder to set and easier to miss.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
P
Hello,
On 11/14/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Stanislav,
why not use a command-line switch for itinstead an INI option?
An ini setting is perfectly valid in this case, it can/should be set
to off in 5.2.x and enabled in head. A command line options is really
a bad alter
Hello Stanislav,
why not use a command-line switch for itinstead an INI option?
best regards
marcus
Tuesday, November 14, 2006, 10:53:26 PM, you wrote:
>> i thought we were avoiding new inisettings. And also having a new INI
>> option takes some time. So is the result really faster?
> Saves
i thought we were avoiding new inisettings. And also having a new INI
option takes some time. So is the result really faster?
Saves FS access per request. New INI cost is minimal. Now, I think
avoiding INI makes most sense for INIs that change app behavior. This
INI changes almost nothing ex
As I told tony in IRC, I don't care if the behavior gets changed back to
5.2 style, although I don't think this is a BC we need to worry about
keeping. I'll lay money that NOONE is relying on this, and I challenge
any of you to prove me wrong on that count.
How much money? ;) Anyway, if nobod
I'd lay money on someone somewhere having something critical relying
on the traditional behavior. IIRC, this came up before and we decided
to preserve the way it worked.
I don't see any need to change this in 6 or any later version.
As crappy as that may be, BC is BC. :-/
--Wez.
On 11/14/06, S
I can't prove you wrong, but to me it sounds extremely reasonable
that there'd be a lot of lines of code that rely on that behavior
exactly. You believe nobody is using fgets() to read, say, 3
bytes? Unless I'm missing something, whenever someone uses this
function to read an exact number of
Richard,
Really, this has been discussed so many times.
Backwards compatibility breakage accumulates. It's not a
binary. "If we break something we can break everything since it's
broken anyway" is not very convincing. The more you break the worse
things are, the more work you have to do in
Ilia Alshanetsky wrote:
-1. Let's not transform 5.2 into a placeholder for PHP6.
On 14-Nov-06, at 6:50 AM, Matt Wilmas wrote:
Hi all,
Matt
<5_2_binary.txt>
--PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I disagree. We're not
Antony Dovgal wrote:
On 11/14/2006 08:26 AM, Andi Gutmans wrote:
Sounds like something which indeed isn't worth breaking. Was this
intentional?
Sara says it was intentional, that's why I decided to write to the list.
I don't think such intentional breaks should take place in any PHP version.
Hello Dmitry,
i thought we were avoiding new inisettings. And also having a new INI
option takes some time. So is the result really faster?
best regards
marcus
Tuesday, November 14, 2006, 11:42:08 AM, you wrote:
> Hi,
> The following patch adds new INI directive for CGI SAPI.
> It may enable
On Monday 13 November 2006 04:42, Mathias Bank wrote:
> Hallo,
>
> you know, that there was often a discussion about a "ifsetor"
> function. I want to generalize this discussion. If you know LISP,
> there is a fantastic macro function which allows you to generate own
> syntax (not a c macro functio
Hello Richard,
The "#" is needed for CLI mode - thus we won't remove it. In fact we
will not do anything that would cause BC problems. Also there is no
escaping issue with "\". If there is than it is outside of PHP. In
other words:
- "\" is the only single character reachable from 'western' keyboa
Hello,
On 11/14/06, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 11/14/2006 08:56 PM, Pierre wrote:
> Hello,
>
> On 11/14/06, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>> > The comparison Tony made was between <=5.X and PHP 6, I do not believe
>> > anyone is suggesting to modify the 5.2.x beh
On 11/14/2006 08:56 PM, Pierre wrote:
Hello,
On 11/14/06, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> The comparison Tony made was between <=5.X and PHP 6, I do not believe
> anyone is suggesting to modify the 5.2.x behavior.
Yes, I noticed later it's PHP 6, but it does not change a thing
Hello,
On 11/14/06, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> The comparison Tony made was between <=5.X and PHP 6, I do not believe
> anyone is suggesting to modify the 5.2.x behavior.
Yes, I noticed later it's PHP 6, but it does not change a thing - it's
still totally unnecessary BC bre
The comparison Tony made was between <=5.X and PHP 6, I do not believe
anyone is suggesting to modify the 5.2.x behavior.
Yes, I noticed later it's PHP 6, but it does not change a thing - it's
still totally unnecessary BC break for the sake of meaningless purism.
It adds nothing to the languag
I think people who want the performance can disable the check, but we
should not break BC, certainly not at a patch level release.
On 14-Nov-06, at 5:42 AM, Dmitry Stogov wrote:
Hi,
The following patch adds new INI directive for CGI SAPI.
It may enable/disable check for shebang line (#! /us
On 14/11/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
On 14-Nov-06, at 3:34 AM, Stanislav Malyshev wrote:
>> It seems utterly ridiculous to return maxlen-1.
>> Whilst this is sure as hell a BC, it should work "properly". If I ask
>> for 10, I want 10. I wouldn't have asked for 10 otherwise.
On 14-Nov-06, at 3:34 AM, Stanislav Malyshev wrote:
It seems utterly ridiculous to return maxlen-1.
Whilst this is sure as hell a BC, it should work "properly". If I ask
for 10, I want 10. I wouldn't have asked for 10 otherwise. Having to
know the "magic" to get things to work is plainly bad ma
Hello,
On 11/14/06, Sakamoto Kouichi <[EMAIL PROTECTED]> wrote:
Hi,
I can not log in to CVS Server.(Account: kouichi66)
I don't understand what is bad.
Your account is not created. For the tenth time, please *contact* the
pear group and ask them to valid your account request. You will not be
a
-1. Let's not transform 5.2 into a placeholder for PHP6.
On 14-Nov-06, at 6:50 AM, Matt Wilmas wrote:
Hi all,
This is regarding Derick's addition of the (binary) cast in 5.2,
and its
discussion. I agree with the others who think it's a good addition so
future code for PHP 6 won't fail wit
Hi,
I can not log in to CVS Server.(Account: kouichi66)
I don't understand what is bad.
The fact that I implemented:
- Request Account.
*from url http://jp.php.net/cvs-php.php
- Get karma.
*ref:http://cvs.php.net/viewvc.cgi/CVSROOT/avail?r1=1.1194&r2=1.1195
- Setting ~/.cvsrc
cvs -z3
up
Hi,
I am using PHP since 2.0 and would like to contribute something to it. I was
talking to Hartmut Holzgraefe, who told me, that you might need some help with
your German documentation. I would like to offer my help translating English
parts into German. I am a native German speaker and was li
Hi all,
This is regarding Derick's addition of the (binary) cast in 5.2, and its
discussion. I agree with the others who think it's a good addition so
future code for PHP 6 won't fail with a parse error on a small thing that
could be handled transparently.
But the point of this message is to ask
Hi,
The following patch adds new INI directive for CGI SAPI.
It may enable/disable check for shebang line (#! /usr/bin/php) and as result
improve performance of FastCGI.
I set the default value for this directive to 1 (that means check file on
each request) to not break previous behavior.
However
Richard Quadling wrote:
And so why are we losing register_globals? For a LOT of code they work
and removing rg is sure as hell a BC for a lot of code. And we move
This was done for *good* reason. You don't gain a lot of security (or
even code clearity/brevity) by changing fgets. That's the dif
On 14/11/06, Antony Dovgal <[EMAIL PROTECTED]> wrote:
"It works this way since PHP3" means "it works right" even if there was a bug
in PHP3.
That's because thousands of people could rely on this behaviour (which is, I
repeat,
very well documented and pretty much expected).
And so why are we l
Antony Dovgal wrote:
> On 11/14/2006 08:26 AM, Andi Gutmans wrote:
>> Sounds like something which indeed isn't worth breaking. Was this
>> intentional?
>
> Sara says it was intentional, that's why I decided to write to the list.
> I don't think such intentional breaks should take place in any PHP
On 11/14/2006 11:24 AM, Richard Quadling wrote:
As we are often told on this list, PHP is not C.
It seems utterly ridiculous to return maxlen-1.
It also might seem ridiculous to have strlen() and str_replace(), but there are
good reasons to have strlen() instead of str_len().
Whilst this is
On 11/14/2006 08:26 AM, Andi Gutmans wrote:
Sounds like something which indeed isn't worth breaking. Was this
intentional?
Sara says it was intentional, that's why I decided to write to the list.
I don't think such intentional breaks should take place in any PHP version.
-Original Messag
Richard Quadling wrote:
Just because it has always done it doesn't mean it always will. That's
what BC's are about.
BC, as far as I know, is "backwards compatibility". It is *exactly*
about "it has always done so and it always will". And unless there's a
*very* good reason not to do it, so it
The only issue with using \ is the fact that this is the escape
character. If you are using PHP to create classes (collapsing complex
classes into simpler ones, implementing a fake AOP), you have to
remember to escape the escape. It just seems odd to re-use a symbol
like this. A new symbol is bett
Just because it has always done it doesn't mean it always will. That's
what BC's are about.
If this was to be a BC, having it mid version is not a good idea.
Maybe for V6 where a whole LOAD of things are going to change, making
it another part of the clean up process would be a better option.
On
It always returned length-1, manual says length-1, so suddenly in
version 5.2.1 it starts returning length instead. And now imagine
Didn't notice - it is about HEAD not 5.2. It's less critical then but
still as bad. People moving to PHP 6 would have enough things to worry
without changing f
It seems utterly ridiculous to return maxlen-1.
Whilst this is sure as hell a BC, it should work "properly". If I ask
for 10, I want 10. I wouldn't have asked for 10 otherwise. Having to
know the "magic" to get things to work is plainly bad magic.
It always returned length-1, manual says length
As we are often told on this list, PHP is not C.
It seems utterly ridiculous to return maxlen-1.
Whilst this is sure as hell a BC, it should work "properly". If I ask
for 10, I want 10. I wouldn't have asked for 10 otherwise. Having to
know the "magic" to get things to work is plainly bad magic.
Hello Jessie,
Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
> What does everyone else think? Are functions/constants inside namespaces
> really that critical?
> Anyways, I just thought of a possible solution to the namespace
> separator issue, and if it's doable, then the double colon (::
48 matches
Mail list logo
