E_ALL changes in 5.2/6.0

19 years ago by Steph Fox — view source

unread

Marcus,

FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
switched on anywhere but a dev box? - and when there is the option to switch
on E_ALL without E_STRICT, it makes it much easier to miss useful
information about the direction PHP is going in.

Pierre: the biggest E_STRICT issues I'm aware of are the 'vars don't live
here any more' one (which was removed two months ago in PHP_5_1 branch) and
the 'only variables can be passed by reference' one (which is in PHP 4.4.*
anyway). Beyond those two, it ought to be pretty rare to even see an
E_STRICT when you're migrating PHP 4 code to PHP 5 - although it isn't
necessarily rare when you're finding your way around 5.x with new code. But
that's OK, because writing new code following a language upgrade really
should be a learning process - if it isn't, you might as well just stay with
the old version for as long as you can - and if you're learning, having
these mild slaps on the wrist is genuinely useful.

Migrating old code, on the other hand, shouldn't be a learning process
unless there's a real need for that. Given that the vars deprecation notice
is gone, I don't think there's anything unnecessarily blocking the upgrade
path any more in that sense. Correct me if I'm wrong...

Steph

PS Pierre I should've replied to your post instead really, but my mail
client doesn't handle newsgroup posters too well :\

Hello internals,

by accident i added both E_STRICT and E_RECOVERABLE_ERROR to E_ALL
while MFHing new features as discussed beforehand while decision was
only to MFH E_RECOVERABLE_ERROR and not to put E_STRICT into E_ALL.
See: http://oss.backendmedia.com/PhP52

Now the idea of E_STRICT is that core developers can inform users about
changes in upcoming versions of php as early as possible. So developers
should have E_ALL including E_STRICT enabled during development so that
they are able to develop clean applications that most likely will work
in the next version. On the production machines you would still either
not use E_ALL or log only and don't show the errors in the application.

That said i am about to not remove E_STRICT from E_ALL and MFH the php
6.0 to item just now.
See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE
(dmitry))

Since this is for the benefit of the users to prevent issues with
changes in behavior from my opinion it is best to do this behavior
change as early as possible, which is in my opinion 5.2 anyway.

That said i'll let it in and if there is no valid argument against, i
will put it into the NEWS file and the newly started README.UPDATE_5_2.

Best regards,
Marcus

--

__________ NOD32 1.1380 (20060125) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

19 years ago by Greg Beaver — view source

unread

Steph Fox wrote:

Marcus,

FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
switched on anywhere but a dev box? - and when there is the option to
switch on E_ALL without E_STRICT, it makes it much easier to miss
useful information about the direction PHP is going in.

Pierre: the biggest E_STRICT issues I'm aware of are the 'vars don't
live here any more' one (which was removed two months ago in PHP_5_1
branch) and the 'only variables can be passed by reference' one (which
is in PHP 4.4.* anyway). Beyond those two, it ought to be pretty rare

Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()

This is of course going to be a fatal in PHP 6, but it is now the most
common E_STRICT I see in PHP4-based code.

I agree that it is appropriate to change something like this in a 5.X.0,
but it will be a headache for anyone running legacy apps (not just
PEAR). Until someone writes some killer apps in PHP5 to replace phpBB
and company, changes of this nature will simply prevent moving to PHP5
but that's another story and not the concern of internals (I agree with
this strongly). If you all are willing to deal with the fallout (think
PHP 4.4) then that's that.

Greg

19 years ago by Ilia Alshanetsky — view source

unread

My opinion is that if we intend to make something stop working (give
fatal error) in future releases we need to provide some form of
notice be it E_STRICT or E_NOTICE to our users now, so they can
anticipate the change. As far as inclusion of E_STRICT into E_ALL, I
think this is a good idea, but is probably premature for the 5.2
release.

Steph Fox wrote:

Marcus,

FWIW I'm with you (unusually) over E_STRICT. Why would anyone have
E_ALL
switched on anywhere but a dev box? - and when there is the option to
switch on E_ALL without E_STRICT, it makes it much easier to miss
useful information about the direction PHP is going in.

Pierre: the biggest E_STRICT issues I'm aware of are the 'vars don't
live here any more' one (which was removed two months ago in PHP_5_1
branch) and the 'only variables can be passed by reference' one
(which
is in PHP 4.4.* anyway). Beyond those two, it ought to be pretty
rare

Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()

This is of course going to be a fatal in PHP 6, but it is now the most
common E_STRICT I see in PHP4-based code.

I agree that it is appropriate to change something like this in a
5.X.0,
but it will be a headache for anyone running legacy apps (not just
PEAR). Until someone writes some killer apps in PHP5 to replace phpBB
and company, changes of this nature will simply prevent moving to PHP5
but that's another story and not the concern of internals (I agree
with
this strongly). If you all are willing to deal with the fallout
(think
PHP 4.4) then that's that.

Greg

--

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

19 years ago by Derick Rethans — view source

unread

My opinion is that if we intend to make something stop working (give fatal
error) in future releases we need to provide some form of notice be it
E_STRICT or E_NOTICE to our users now, so they can anticipate the change. As
far as inclusion of E_STRICT into E_ALL, I think this is a good idea, but is
probably premature for the 5.2 release.

Then when do you suggest we add it (before 6.0)?

regards,
Derick

19 years ago by Ilia Alshanetsky — view source

unread

I suggest that we add E_STRICT now, but not include E_STRICT into
E_ALL, so people who are not using E_STRICT error reporting level
don't have their applications start spewing strict messages.
We cannot force people to change their code, all we can reasonably do
is provide notification mechanism, for those who do.

My opinion is that if we intend to make something stop working
(give fatal
error) in future releases we need to provide some form of notice
be it
E_STRICT or E_NOTICE to our users now, so they can anticipate the
change. As
far as inclusion of E_STRICT into E_ALL, I think this is a good
idea, but is
probably premature for the 5.2 release.

Then when do you suggest we add it (before 6.0)?

regards,
Derick

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

19 years ago by Marcus Boerger — view source

unread

Hello Ilia,

Monday, May 15, 2006, 3:23:18 PM, you wrote:

I suggest that we add E_STRICT now, but not include E_STRICT into
E_ALL,

We added E_STRICT in what 5.0 or or 5.1? Guess i checked it:
marcus@zaphod /usr/src/php-cvs $ cvs annotate Zend/zend_errors.h|grep E_STRICT

Annotations for Zend/zend_errors.h

1.15 (andi 18-Nov-03): #define E_STRICT (1<<11L)
1.22 (dmitry 16-Mar-06): #define E_ALL (E_ERROR | E_WARNING | E_PARSE | E_N
marcus@zaphod /usr/src/php-cvs $ cvs log Zend/zend_errors.h|grep php_5_0_0b
php_5_0_0b4: 1.17
php_5_0_0b4RC1: 1.17
php_5_0_0b3: 1.16
php_5_0_0b3RC2: 1.16
php_5_0_0b3RC1: 1.16
php_5_0_0b2: 1.14
php_5_0_0b2RC1: 1.14
php_5_0_0b1: 1.14
marcus@zaphod /usr/src/php-cvs $

so people who are not using E_STRICT error reporting level
don't have their applications start spewing strict messages.
We cannot force people to change their code, all we can reasonably do
is provide notification mechanism, for those who do.

Yes and that is E_STRICT. And if we continue the way we do now we will have
not only unicode problems when people upgrade to 6...

My opinion is that if we intend to make something stop working
(give fatal
error) in future releases we need to provide some form of notice
be it
E_STRICT or E_NOTICE to our users now, so they can anticipate the
change. As
far as inclusion of E_STRICT into E_ALL, I think this is a good
idea, but is
probably premature for the 5.2 release.

Then when do you suggest we add it (before 6.0)?

regards,
Derick

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

Best regards,
Marcus

19 years ago by Ilia Alshanetsky — view source

unread

Erhm... I meant, add E_STRICT warning message to the code to the
deprecated oo code.

Hello Ilia,

Monday, May 15, 2006, 3:23:18 PM, you wrote:

I suggest that we add E_STRICT now, but not include E_STRICT into
E_ALL,

We added E_STRICT in what 5.0 or or 5.1? Guess i checked it:
marcus@zaphod /usr/src/php-cvs $ cvs annotate Zend/zend_errors.h|
grep E_STRICT

Annotations for Zend/zend_errors.h

1.15 (andi 18-Nov-03): #define
E_STRICT (1<<11L)
1.22 (dmitry 16-Mar-06): #define E_ALL (E_ERROR |
E_WARNING | E_PARSE | E_N
marcus@zaphod /usr/src/php-cvs $ cvs log Zend/zend_errors.h|grep
php_5_0_0b
php_5_0_0b4: 1.17
php_5_0_0b4RC1: 1.17
php_5_0_0b3: 1.16
php_5_0_0b3RC2: 1.16
php_5_0_0b3RC1: 1.16
php_5_0_0b2: 1.14
php_5_0_0b2RC1: 1.14
php_5_0_0b1: 1.14
marcus@zaphod /usr/src/php-cvs $

so people who are not using E_STRICT error reporting level
don't have their applications start spewing strict messages.
We cannot force people to change their code, all we can reasonably do
is provide notification mechanism, for those who do.

Yes and that is E_STRICT. And if we continue the way we do now we
will have
not only unicode problems when people upgrade to 6...

My opinion is that if we intend to make something stop working
(give fatal
error) in future releases we need to provide some form of notice
be it
E_STRICT or E_NOTICE to our users now, so they can anticipate the
change. As
far as inclusion of E_STRICT into E_ALL, I think this is a good
idea, but is
probably premature for the 5.2 release.

Then when do you suggest we add it (before 6.0)?

regards,
Derick

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

Best regards,
Marcus

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

19 years ago by Todd Ruth — view source

unread

...

Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()

This is of course going to be a fatal in PHP 6, but it is now the most
common E_STRICT I see in PHP4-based code.

Yikes! Please say it isn't so! There are significant portions of
our app that rely on php's ability to make "semi-static" calls. It
would never be worth the cost of upgrading to php6 if that were the
case.

It's not the best style, but we have scores of classes that
have several members in common and need common functionality
for those members. In php5 and earlier, you can add helper
classes and call helper functions with the "::" syntax. The
helper can access all of the members of the main class as if
it were its own. The "right" thing to do would be to step
back in the design and move the members to other classes,
etc., but as practical matter, sometimes that's just not
worth the effort to make such drastic changes to code that's
developed by accretion.

Another use is that we have core data that most classes keep
in an "$application" member variable. It's sort of like a
global, but to allow for a couple instances of a class to
work on different app data, we've taken the member route
instead of the global route. php is a nice language for this
in that we don't have to pass $application to every static
function we call. The static function has access to
$this->application, because everyone who calls the static
function has the application member.

Please don't fatal error this code in php 6!

Thanks for listening,
Todd

19 years ago by Marcus Boerger — view source

unread

Hello Todd,

Monday, May 15, 2006, 6:03:14 PM, you wrote:

...

Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()

This is of course going to be a fatal in PHP 6, but it is now the most
common E_STRICT I see in PHP4-based code.

Yikes! Please say it isn't so! There are significant portions of
our app that rely on php's ability to make "semi-static" calls. It
would never be worth the cost of upgrading to php6 if that were the
case.

It's not the best style, but we have scores of classes that
have several members in common and need common functionality
for those members. In php5 and earlier, you can add helper
classes and call helper functions with the "::" syntax. The
helper can access all of the members of the main class as if
it were its own. The "right" thing to do would be to step
back in the design and move the members to other classes,
etc., but as practical matter, sometimes that's just not
worth the effort to make such drastic changes to code that's
developed by accretion.

Another use is that we have core data that most classes keep
in an "$application" member variable. It's sort of like a
global, but to allow for a couple instances of a class to
work on different app data, we've taken the member route
instead of the global route. php is a nice language for this
in that we don't have to pass $application to every static
function we call. The static function has access to
$this->application, because everyone who calls the static
function has the application member.

Please don't fatal error this code in php 6!

Thanks for listening,
Todd

Ever heared of the concept named root class?

19 years ago by Todd Ruth — view source

unread

Monday, May 15, 2006, 6:03:14 PM, you wrote:

...

Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()

This is of course going to be a fatal in PHP 6, but it is now the most
common E_STRICT I see in PHP4-based code.

Yikes! Please say it isn't so! There are significant portions of
our app that rely on php's ability to make "semi-static" calls. It
would never be worth the cost of upgrading to php6 if that were the
case.

It's not the best style, but we have scores of classes that
have several members in common and need common functionality
for those members. In php5 and earlier, you can add helper
classes and call helper functions with the "::" syntax. The
helper can access all of the members of the main class as if
it were its own. The "right" thing to do would be to step
back in the design and move the members to other classes,
etc., but as practical matter, sometimes that's just not
worth the effort to make such drastic changes to code that's
developed by accretion.

Another use is that we have core data that most classes keep
in an "$application" member variable. It's sort of like a
global, but to allow for a couple instances of a class to
work on different app data, we've taken the member route
instead of the global route. php is a nice language for this
in that we don't have to pass $application to every static
function we call. The static function has access to
$this->application, because everyone who calls the static
function has the application member.

Please don't fatal error this code in php 6!

Thanks for listening,
Todd

Ever heared of the concept named root class?

Yes, but it isn't a substitute for the semi-statics. Including
comments, etc., our php files total about 130,000 lines. If it
were a small, simple app, I could shove the helpers into a root
class and it wouldn't be much worse than the search & replaces
needed to get to php5. The arguments against our code would be
the standard arguments against multiple inheritance. (The semi-
statics provide something very similar to multiple inheritance.)
Like many large apps that have evolved over many years, this isn't
because it was designed that way; it is because much of it wasn't
designed at all. It just grew. The good news is that it ran
great on php4 and it hasn't been too much trouble to get rid of
the issues with getting it to run great on php5. I'm hoping
php6 doesn't give up so much backward compatibility that we'll
never be able to use it.

BTW, I've tried to come up with a short example to give a flavor
of what I want to preserve, but anything short is too easy to
refactor and say "it should have been done differently". It's
true that many aspects of our app should have been done
differently, but its difficult to change something so large.
I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6. Is there a significant performance
enhancement in the engine that depends on eliminating semi-static
or somesuch?

Todd

19 years ago by Marcus Boerger — view source

unread

Hello Todd,

Monday, May 15, 2006, 9:32:21 PM, you wrote:

Monday, May 15, 2006, 6:03:14 PM, you wrote:

...

Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()

This is of course going to be a fatal in PHP 6, but it is now the most
common E_STRICT I see in PHP4-based code.

Yikes! Please say it isn't so! There are significant portions of
our app that rely on php's ability to make "semi-static" calls. It
would never be worth the cost of upgrading to php6 if that were the
case.

It's not the best style, but we have scores of classes that
have several members in common and need common functionality
for those members. In php5 and earlier, you can add helper
classes and call helper functions with the "::" syntax. The
helper can access all of the members of the main class as if
it were its own. The "right" thing to do would be to step
back in the design and move the members to other classes,
etc., but as practical matter, sometimes that's just not
worth the effort to make such drastic changes to code that's
developed by accretion.

Another use is that we have core data that most classes keep
in an "$application" member variable. It's sort of like a
global, but to allow for a couple instances of a class to
work on different app data, we've taken the member route
instead of the global route. php is a nice language for this
in that we don't have to pass $application to every static
function we call. The static function has access to
$this->application, because everyone who calls the static
function has the application member.

Please don't fatal error this code in php 6!

Thanks for listening,
Todd

Ever heared of the concept named root class?

Yes, but it isn't a substitute for the semi-statics. Including
comments, etc., our php files total about 130,000 lines. If it
were a small, simple app, I could shove the helpers into a root
class and it wouldn't be much worse than the search & replaces
needed to get to php5. The arguments against our code would be
the standard arguments against multiple inheritance. (The semi-
statics provide something very similar to multiple inheritance.)
Like many large apps that have evolved over many years, this isn't
because it was designed that way; it is because much of it wasn't
designed at all. It just grew. The good news is that it ran
great on php4 and it hasn't been too much trouble to get rid of
the issues with getting it to run great on php5. I'm hoping
php6 doesn't give up so much backward compatibility that we'll
never be able to use it.

PHP also offers interfaces.

BTW, I've tried to come up with a short example to give a flavor
of what I want to preserve,

No need, i'd just figure misdesign.

[...] Is there a significant performance
enhancement in the engine that depends on eliminating semi-static
or somesuch?

Security. We might as well enable the crash function in non debug builds.
Or just drop 'static' again and go back to the PHP 4 object model.

Best regards,
Marcus

19 years ago by Richard Lynch — view source

unread

[...] Is there a significant performance
enhancement in the engine that depends on eliminating semi-static
or somesuch?

Security. We might as well enable the crash function in non debug
builds.
Or just drop 'static' again and go back to the PHP 4 object model.

I realize I'm the village idiot here, but...

How does throwing, say, E_NOTICE or E_OOP_PURIST or something instead
of E_FATAL when the programmer does this, turn into a crashing
security issue?

While encapsulation can be an important component of data-integrity
and security in an application's OOP model, I'm just not seeing this
as a general security flaw that should halt somebody's program because
they prefer a looser encapsulation model in their OOP...

Am I being particularly naive or blind here?

If so, could you elaborate on how this is a Security concern, and
equates with a crash function in non debug builds?

Much less regressing to the inherently flawed PHP4 OOP model?

If you're sure I'm the only idiot not getting this, feel free to point
me to references or reply off-list or just ignore me, as I know you're
crazy busy. :-)

--
Like Music?
http://l-i-e.com/artists.htm

19 years ago by Edin Kadribasic — view source

unread

Todd Ruth wrote:

I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.

My sentiments exactly. OO purity/strictness do now work well with PHP's
main strength -- its dynamicity.

Edin

19 years ago by Sebastian Bergmann — view source

unread

Edin Kadribasic wrote:

OO purity/strictness do now work well with PHP's main strength -- its
dynamicity.

You make it sound like OO and dynamicity were mutually exclusive; they
are not. Take a look at Smalltalk or CLOS to see what I mean.

--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

19 years ago by Edin Kadribasic — view source

unread

Sebastian Bergmann wrote:

Edin Kadribasic wrote:

OO purity/strictness do now work well with PHP's main strength -- its
dynamicity.

You make it sound like OO and dynamicity were mutually exclusive; they
are not. Take a look at Smalltalk or CLOS to see what I mean.

I know, but often the arguments used here against dynamicity is that it
does not comply with some pure computer science OO paradigm. I do belive
PHP can support nice object model and remain dynamic at the same time.

Edin

19 years ago by Richard Lynch — view source

unread

Edin Kadribasic wrote:

OO purity/strictness do now work well with PHP's main strength --
its
dynamicity.

You make it sound like OO and dynamicity were mutually exclusive;
they
are not. Take a look at Smalltalk or CLOS to see what I mean.

Hey, anytime the OO purists designing the PHP OO language want to
abandon Java concepts and head for Lisp or even Smalltalk, I'm all for
it :-) :-) :-)

PHP's Java-like OOP and dynamicity are at odds -- All the
requirements of declaring things up front are simply not dynamic in
nature.

Some folks like it that way ; Some don't.

The guys doing all the work like it that way, so there ya go.
[shrug]

My simple solution to this problem has been to largely ignore PHP OOP :-)

--
Like Music?
http://l-i-e.com/artists.htm

19 years ago by Andi Gutmans — view source

unread

I don't see why it has to be a fatal error. If there's an instanceof
relationship we can keep $this. If not, we should not pass $this
(which I believe we already do in PHP 5), in which case the author
would have to pass $this if he wants to change public properties.

Andi

At 12:49 PM 5/15/2006, Edin Kadribasic wrote:

Todd Ruth wrote:

I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.

My sentiments exactly. OO purity/strictness do now work well with
PHP's main strength -- its dynamicity.

Edin

19 years ago by Todd Ruth — view source

unread

In php5 this works even without an instanceof relationship.
(I'm running 5.1.2 and this test gets a "PASS" from run-tests.php.)
I know the following test case does not even remotely follow
good OO design principles, but it's hard to imagine us going
back to the drawing board with our app. Please don't break
the following in php6 just to teach me a lesson about OO design.

If there's a repository of "someone will complain about a BC
break if this changes" tests, please add the following:

--TEST--
test that $this survives in a semi-static call
--FILE--
<?php
class TheParent {
public $x = 3;
}
class UglyUncle {
function f() {
$this->x = 5;
}
}
class Child extends TheParent {
function f() {
UglyUncle::f();
}
}
$c = new Child();
var_dump($c->x);
$c->f();
var_dump($c->x);
?>
--EXPECT--
int(3)
int(5)

Thanks,
Todd

I don't see why it has to be a fatal error. If there's an instanceof
relationship we can keep $this. If not, we should not pass $this
(which I believe we already do in PHP 5), in which case the author
would have to pass $this if he wants to change public properties.

Andi

At 12:49 PM 5/15/2006, Edin Kadribasic wrote:

Todd Ruth wrote:

I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.

My sentiments exactly. OO purity/strictness do now work well with
PHP's main strength -- its dynamicity.

Edin

--

--
Todd Ruth <truth@proposaltech.com

19 years ago by Marcus Boerger — view source

unread

Hello Todd,

if you need abstract static methods that oo wise make no sense at all
but still want them because you know your stuff better than theory then
there still is a problem in the engine code we have to maintain. In case
we had late static binding already we might have solved all related
issues alredy. In the current state the behavior is likely to cause
trouble in some cases becuase the engine was not designed to support oo
misuse/wron use. It was just an oversight not to have that test on the
place - most likely on my side, since i wrote all tests and a lot of the
oo rules code. Now that we are finally working with PHP 5 and more than
1% of our users do so as well we find more and more issues.

This situation is just like the one where we had to fix reference stuff
as we found out that it indeed was causing SEGVs in certain situations.
And i want to provide such situations and i want that at nearly all
costs because i do not want to have such a situation again. For one
reason it took me like a full week of work to help Derick with a tiny
piece in debugging and i don't know how much time Derick spend on
tracking the issue down and fixing it. In short i rather drop a feature
than risking SEGVs.

Now decide for your self what is more expensive/more dangerous for you?
An unstablel PHP or a tiny feature loss?

Btw, right now you can have abstract static methods in interfaces. This
was a compromise I introduced when we found out the issue.

marcus

Wednesday, May 24, 2006, 8:56:06 PM, you wrote:

In php5 this works even without an instanceof relationship.
(I'm running 5.1.2 and this test gets a "PASS" from run-tests.php.)
I know the following test case does not even remotely follow
good OO design principles, but it's hard to imagine us going
back to the drawing board with our app. Please don't break
the following in php6 just to teach me a lesson about OO design.

If there's a repository of "someone will complain about a BC
break if this changes" tests, please add the following:

--TEST--
test that $this survives in a semi-static call
--FILE--
<?php
class TheParent {
public $x = 3;
}
class UglyUncle {
function f() {
$this->x = 5;
}
}
class Child extends TheParent {
function f() {
UglyUncle::f();
}
}
$c = new Child();
var_dump($c->x);
$c->f();
var_dump($c->x);
?>>
--EXPECT--
int(3)
int(5)

Thanks,
Todd

I don't see why it has to be a fatal error. If there's an instanceof
relationship we can keep $this. If not, we should not pass $this
(which I believe we already do in PHP 5), in which case the author
would have to pass $this if he wants to change public properties.

Andi

At 12:49 PM 5/15/2006, Edin Kadribasic wrote:

Todd Ruth wrote:

I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.

My sentiments exactly. OO purity/strictness do now work well with
PHP's main strength -- its dynamicity.

Edin

--

Best regards,
Marcus

19 years ago by Christian Schneider — view source

unread

One caveat with making a static call to a non-static function a fatal
error is that it will make use of static calls impossible for code which
wants to be PHP4 and PHP6 compatible, no? You probably don't care but I
still wanted to mention it.

E_STRICT is nice for people who are able to move their code base to pure
PHP5 but not everybody can do that. Which means that converting E_STRICT
to E_FATAL should be done with care. But it's obviously up to you guys
to decide when the grace period is over...

Oh, one thing which would help would be if certain E_STRICT errors could
be (optionally) reported at compile time to not have to depend on code
coverage tests. E.g. A::foo() could (optionally) report an E_STRICT if
class A with a non-static method foo is already defined when
encountering the call. Maybe the lint-mode could be used for that.

PS: There are no plans to make non-static calls to static methods
illegal, right?

Chris

19 years ago by Jasper Bryant-Greene — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Christian Schneider wrote:

PS: There are no plans to make non-static calls to static methods
illegal, right?

What is the point in that? What advantage do you get using
$this->someMethodName() [non-static call] over self::someMethodName()
[static call]?

Jasper Bryant-Greene
General Manager
Album Limited

http://www.album.co.nz/ 0800 4 ALBUM
jasper@album.co.nz 021 708 334
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEdZo6FfAeHhDzT4gRA/+SAKChatBRNsYIbxg42oQ6wOB9eOGY7wCg1mnc
3KjgLHqnuV4j+fDlCCUAT/g=
=k/j5
-----END PGP SIGNATURE

19 years ago by Christian Schneider — view source

unread

Jasper Bryant-Greene wrote:

Christian Schneider wrote:

PS: There are no plans to make non-static calls to static methods
illegal, right?

What is the point in that? What advantage do you get using
$this->someMethodName() [non-static call] over self::someMethodName()
[static call]?

self:: does not exist in PHP 4. So $this is probably used by some people
to avoid <classname>:: which is ugly. While this might not be the best
reason to do it it is still a real world fact.

Chris

19 years ago by Edin Kadribasic — view source

unread

Jasper Bryant-Greene wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Christian Schneider wrote:

PS: There are no plans to make non-static calls to static methods
illegal, right?

What is the point in that? What advantage do you get using
$this->someMethodName() [non-static call] over self::someMethodName()
[static call]?

You don't need to create an object to make a static call.
MyClass::MyFunc() works without objects, which is much faster than
creating an instance and then invoking a method on it.

Edin

19 years ago by Jasper Bryant-Greene — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Edin Kadribasic wrote:

Jasper Bryant-Greene wrote:

Christian Schneider wrote:

PS: There are no plans to make non-static calls to static methods
illegal, right?

What is the point in that? What advantage do you get using
$this->someMethodName() [non-static call] over self::someMethodName()
[static call]?

You don't need to create an object to make a static call.
MyClass::MyFunc() works without objects, which is much faster than
creating an instance and then invoking a method on it.

Exactly. You just gave an advantage of calling a static method using a
static call over a non-static call.

Now back to my original question, which actually relates to the OP's
question: what advantage do you get calling a static method using a
non-static call over a static call?

Jasper Bryant-Greene
General Manager
Album Limited

http://www.album.co.nz/ 0800 4 ALBUM
jasper@album.co.nz 021 708 334
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEdiruFfAeHhDzT4gRAwrJAKDvomdAlns/khNuwFDMMKcZXuT9DACgme9b
/S4/8LUgYSL/Nsex8akNFaY=
=ykGX
-----END PGP SIGNATURE

19 years ago by Marcus Boerger — view source

unread

Hello Christian,

Thursday, May 25, 2006, 1:47:24 PM, you wrote:

One caveat with making a static call to a non-static function a fatal
error is that it will make use of static calls impossible for code which
wants to be PHP4 and PHP6 compatible, no? You probably don't care but I
still wanted to mention it.

There is no way you can write heavy oo using code that supports PHP 4
and PHP 5.2 without a version check every here and there, so i don't see
this as an argument. It is a fact that 4 and 5 have very different object
models.

PS: There are no plans to make non-static calls to static methods
illegal, right?

Of course not :-)

Best regards,
Marcus

19 years ago by Christian Schneider — view source

unread

Marcus Boerger wrote:

There is no way you can write heavy oo using code that supports PHP 4
and PHP 5.2 without a version check every here and there, so i don't see

I'm not talking about heavy OO code. Just very basic one which static
methods are used as sort-of namespaces. And that works perfectly well in
PHP 4 and PHP 5. I'm just trying to point out that OO in PHP isn't all
or nothing and the argument "if you don't need it, don't use it" has
implications on how BC is treated.

Requiring the static keyword with PHP 6 on the other hand means you get
a compilation error with PHP 4.

Chris

19 years ago by Marcus Boerger — view source

unread

Hello Christian,

Thursday, May 25, 2006, 3:39:02 PM, you wrote:

Marcus Boerger wrote:

There is no way you can write heavy oo using code that supports PHP 4
and PHP 5.2 without a version check every here and there, so i don't see

I'm not talking about heavy OO code. Just very basic one which static
methods are used as sort-of namespaces. And that works perfectly well in
PHP 4 and PHP 5. I'm just trying to point out that OO in PHP isn't all
or nothing and the argument "if you don't need it, don't use it" has
implications on how BC is treated.

Requiring the static keyword with PHP 6 on the other hand means you get
a compilation error with PHP 4.

There are no static methods in PHP 4.

Best regards,
Marcus

19 years ago by Edin Kadribasic — view source

unread

Marcus Boerger wrote:

There are no static methods in PHP 4.

Of course there are. You just don't need to declare them as static. You
know, there used to be a time where not everything needed to be declared
in PHP.

Edin

19 years ago by Todd Ruth — view source

unread

There is no way you can write heavy oo using code that supports PHP 4
and PHP 5.2 without a version check every here and there, so i don't see
this as an argument. It is a fact that 4 and 5 have very different object
models.

Sort of. The fact that "$object1 = $object2" didn't mean
"$object1 =& $object2" in php4 drove us crazy, so each of
our objects keeps its data in an array. For us, moving
from 4 to 5 was mostly about adding "strtolower"s. We
already had our own cloning function, so the only reason
we can't go back to 4 is that we're using Derick's date
stuff. That was the "killer feature" for us that got us
to php 5. The object stuff has not been an issue. Perhaps
you're implying that my life will be difficult if I move
from 5.1 to 5.2, but hopefully that won't be too painful.
BTW, the phpt I posted that uses $this in a static call
doesn't even give a strict message in 5.1.2. It passes
with 0 messages even with "E_ALL|E_STRICT".

BTW, a big thanks to Derick for the timezone feature!
(not to overshadow my thanks to you for the numerous
handy patches I've seen you post!)

Thanks,
Todd

19 years ago by Alan Knowles — view source

unread

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

It would be nice to back port this to PHP4, but at least make the future
BC Breaks more bareable...

Regards
Alan

Christian Schneider wrote:

One caveat with making a static call to a non-static function a fatal
error is that it will make use of static calls impossible for code
which wants to be PHP4 and PHP6 compatible, no? You probably don't
care but I still wanted to mention it.

E_STRICT is nice for people who are able to move their code base to
pure PHP5 but not everybody can do that. Which means that converting
E_STRICT to E_FATAL should be done with care. But it's obviously up to
you guys to decide when the grace period is over...

Oh, one thing which would help would be if certain E_STRICT errors
could be (optionally) reported at compile time to not have to depend
on code coverage tests. E.g. A::foo() could (optionally) report an
E_STRICT if class A with a non-static method foo is already defined
when encountering the call. Maybe the lint-mode could be used for that.

PS: There are no plans to make non-static calls to static methods
illegal, right?

Chris

19 years ago by Pierre — view source

unread

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

The most important point to discuss for any BC break is about why
introduce it. Purity and OO compliance are not good reasons, imho.

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

Is it not the idea behind the preprocessor proposal? (see todo wiki).

--Pierre

19 years ago by Zeev Suraski — view source

unread

At 03:57 26/05/2006, Alan Knowles wrote:

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

What's the semantics of that? The code inside doesn't get executed
if it's not the define()'d PHP version?

Zeev

19 years ago by Alan Knowles — view source

unread

actaully it should have been declare() - as I think the syntax for that
almost works already, but yes, code doesnt get compiled if it's inside a
block.

Regards
Alan

Zeev Suraski wrote:

At 03:57 26/05/2006, Alan Knowles wrote:

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

What's the semantics of that? The code inside doesn't get executed if
it's not the define()'d PHP version?

Zeev

19 years ago by Zeev Suraski — view source

unread

I read it as if it was declare() ;)

I agree with Pierre that the best way to handle BC break is not to
introduce it, but since that's not always 100% possible, this may
make sense. Of course, it'll only work with stuff that is
syntax-compliant with the currently running PHP version, but that
covers most BC breakage.

Zeev

At 04:57 26/05/2006, Alan Knowles wrote:

actaully it should have been declare() - as I think the syntax for that
almost works already, but yes, code doesnt get compiled if it's inside a
block.

Regards
Alan

Zeev Suraski wrote:

At 03:57 26/05/2006, Alan Knowles wrote:

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

What's the semantics of that? The code inside doesn't get executed if
it's not the define()'d PHP version?

Zeev

19 years ago by Marcus Boerger — view source

unread

Hello Zeev,

actually there is a student working on a pre-processor for his summer
of code project. And that will most likely cover versioning, too.

best regards
marcus

Friday, May 26, 2006, 4:06:00 AM, you wrote:

I read it as if it was declare() ;)

I agree with Pierre that the best way to handle BC break is not to
introduce it, but since that's not always 100% possible, this may
make sense. Of course, it'll only work with stuff that is
syntax-compliant with the currently running PHP version, but that
covers most BC breakage.

Zeev

At 04:57 26/05/2006, Alan Knowles wrote:

actaully it should have been declare() - as I think the syntax for that
almost works already, but yes, code doesnt get compiled if it's inside a
block.

Regards
Alan

Zeev Suraski wrote:

At 03:57 26/05/2006, Alan Knowles wrote:

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

What's the semantics of that? The code inside doesn't get executed if
it's not the define()'d PHP version?

Zeev

Best regards,
Marcus

19 years ago by Zeev Suraski — view source

unread

Yeah I heard, but it doesn't mean it'll become a part of the language
(doesn't mean that it would not, but as usual, no discussion ;).

What Alan suggested is already a part of the language, bares no
additional overhead (both CPU cycles and brain cycles), and also
(least important point) is very easy to implement.

Zeev

At 05:08 26/05/2006, Marcus Boerger wrote:

Hello Zeev,

actually there is a student working on a pre-processor for his summer
of code project. And that will most likely cover versioning, too.

best regards
marcus

Friday, May 26, 2006, 4:06:00 AM, you wrote:

I read it as if it was declare() ;)

I agree with Pierre that the best way to handle BC break is not to
introduce it, but since that's not always 100% possible, this may
make sense. Of course, it'll only work with stuff that is
syntax-compliant with the currently running PHP version, but that
covers most BC breakage.

Zeev

At 04:57 26/05/2006, Alan Knowles wrote:

actaully it should have been declare() - as I think the syntax for that
almost works already, but yes, code doesnt get compiled if it's inside a
block.

Regards
Alan

Zeev Suraski wrote:

At 03:57 26/05/2006, Alan Knowles wrote:

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

What's the semantics of that? The code inside doesn't get executed if
it's not the define()'d PHP version?

Zeev

Best regards,
Marcus

19 years ago by Christopher Kings-Lynne — view source

unread

Hi,

I'm starting on a pg_real_escape_string and pg_real_escape_bytea
function for PostgreSQL, based on this security release:

http://www.postgresql.org/docs/techdocs.49

Is anyone else working on it, or is it fine that I do it? I'll let you
know if it's going to take me too long.

Basically the new functions are analagous to the
mysql_real_escape_string function. The difference will be that the
pgsql function will have the optional DB connection resource as the
first parameter rather than the second. (Same as other pgsql functions)

Any comments?

There may be cause to backport these functions ... although the existing
pg_escape_string function is safe in a single threaded context. That's
your guys call.

Chris

19 years ago by Christopher Kings-Lynne — view source

unread

As a follow up I've attached my initial patch for this. Can people
please review?

Chris

Christopher Kings-Lynne wrote:

Hi,

I'm starting on a pg_real_escape_string and pg_real_escape_bytea
function for PostgreSQL, based on this security release:

http://www.postgresql.org/docs/techdocs.49

Is anyone else working on it, or is it fine that I do it? I'll let you
know if it's going to take me too long.

Basically the new functions are analagous to the
mysql_real_escape_string function. The difference will be that the
pgsql function will have the optional DB connection resource as the
first parameter rather than the second. (Same as other pgsql functions)

Any comments?

There may be cause to backport these functions ... although the existing
pg_escape_string function is safe in a single threaded context. That's
your guys call.

Chris

19 years ago by Marcus Boerger — view source

unread

Hello Christopher,

there's an interesting detail in you patch i never used in the for you
did: php_error_docref("function.pg-real-escape-bytea" ...) where the name
you passed in is different from the name of the function. That works as
expected? On the same thing, you say that the function is deprecated.
You may however want to flag the teh deprecated function using the
corresponding flag: ZEND_ACC_DEPRECATED.

Rest looks correct - of course.

best regards
marcus

Monday, May 29, 2006, 8:02:57 AM, you wrote:

As a follow up I've attached my initial patch for this. Can people
please review?

Chris

Christopher Kings-Lynne wrote:

Hi,

I'm starting on a pg_real_escape_string and pg_real_escape_bytea
function for PostgreSQL, based on this security release:

http://www.postgresql.org/docs/techdocs.49

Is anyone else working on it, or is it fine that I do it? I'll let you
know if it's going to take me too long.

Basically the new functions are analagous to the
mysql_real_escape_string function. The difference will be that the
pgsql function will have the optional DB connection resource as the
first parameter rather than the second. (Same as other pgsql functions)

Any comments?

There may be cause to backport these functions ... although the existing
pg_escape_string function is safe in a single threaded context. That's
your guys call.

Chris

Best regards,
Marcus

19 years ago by Lukas Smith — view source

unread

Marcus Boerger wrote:

As a follow up I've attached my initial patch for this. Can people
please review?

Without having looked at the implementation:
Does this implementation also deal with changes in the client encoding?

http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html

This might require hooking into pg_client_encoding() ..

AFAIK this is what will happen in mysqli ..

regards,
Lukas

19 years ago by Christopher Kings-Lynne — view source

unread

Here's a question. The docs for mysql_real_escape_string claim that it
checks the magic_quotes_gpc setting and will stripslashes()
automatically. However, I see nothing in the code that indicates this.
Is it a documentation error?

Chris

Christopher Kings-Lynne wrote:

As a follow up I've attached my initial patch for this. Can people
please review?

Chris

Christopher Kings-Lynne wrote:

Hi,

I'm starting on a pg_real_escape_string and pg_real_escape_bytea
function for PostgreSQL, based on this security release:

http://www.postgresql.org/docs/techdocs.49

Is anyone else working on it, or is it fine that I do it? I'll let
you know if it's going to take me too long.

Basically the new functions are analagous to the
mysql_real_escape_string function. The difference will be that the
pgsql function will have the optional DB connection resource as the
first parameter rather than the second. (Same as other pgsql functions)

Any comments?

There may be cause to backport these functions ... although the
existing pg_escape_string function is safe in a single threaded
context. That's your guys call.

Chris

--
Christopher Kings-Lynne

Technical Manager
CalorieKing
Tel: +618.9389.8777
Fax: +618.9389.8444
chris.kings-lynne@calorieking.com
www.calorieking.com

19 years ago by Jasper Bryant-Greene — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Read the docs again. They do not claim that. I quote:

"Note: If magic_quotes_gpc is enabled, first apply stripslashes() to
the data. Using this function on data which has already been escaped
will escape the data twice." -- http://php.net/mysql_real_escape_string

Jasper

Christopher Kings-Lynne wrote:

Here's a question. The docs for mysql_real_escape_string claim that it
checks the magic_quotes_gpc setting and will stripslashes()
automatically. However, I see nothing in the code that indicates this.
Is it a documentation error?

Chris

Christopher Kings-Lynne wrote:

As a follow up I've attached my initial patch for this. Can people
please review?

Chris

Christopher Kings-Lynne wrote:

Hi,

I'm starting on a pg_real_escape_string and pg_real_escape_bytea
function for PostgreSQL, based on this security release:

http://www.postgresql.org/docs/techdocs.49

Is anyone else working on it, or is it fine that I do it? I'll let
you know if it's going to take me too long.

Basically the new functions are analagous to the
mysql_real_escape_string function. The difference will be that the
pgsql function will have the optional DB connection resource as the
first parameter rather than the second. (Same as other pgsql functions)

Any comments?

There may be cause to backport these functions ... although the
existing pg_escape_string function is safe in a single threaded
context. That's your guys call.

Chris

Jasper Bryant-Greene
General Manager
Album Limited

http://www.album.co.nz/ 0800 4 ALBUM
jasper@album.co.nz 021 708 334
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFEfOkmFfAeHhDzT4gRA3/1AJ40jOrkZfaK+8vScrWlQw7GO3MBwwCfU0ra
KiUywAybyQsqO+J9AZggX/s=
=dYMR
-----END PGP SIGNATURE

19 years ago by Marcus Boerger — view source

unread

Hello Zeev,

actually there was plenty of discussion prior to selecting the summer
of code projects. Nonetheless we will see how it will work out. For example
#line <num> <source> can easily be aded to the lexer already and doesn't
require a full blown preprocessor. Versioning is very different since it
should either be a real preprocessor and thus not doing any harm to php
or it is a language feature and then a bunch of stuff probably has to be
changed. Though maybe even then it is a simple additional state in the
lexer - those tools can be so easy.

Anyway you might want to contact the student.

marcus

Friday, May 26, 2006, 11:04:30 AM, you wrote:

Yeah I heard, but it doesn't mean it'll become a part of the language
(doesn't mean that it would not, but as usual, no discussion ;).

What Alan suggested is already a part of the language, bares no
additional overhead (both CPU cycles and brain cycles), and also
(least important point) is very easy to implement.

Zeev

At 05:08 26/05/2006, Marcus Boerger wrote:

Hello Zeev,

actually there is a student working on a pre-processor for his summer
of code project. And that will most likely cover versioning, too.

best regards
marcus

Friday, May 26, 2006, 4:06:00 AM, you wrote:

I read it as if it was declare() ;)

I agree with Pierre that the best way to handle BC break is not to
introduce it, but since that's not always 100% possible, this may
make sense. Of course, it'll only work with stuff that is
syntax-compliant with the currently running PHP version, but that
covers most BC breakage.

Zeev

At 04:57 26/05/2006, Alan Knowles wrote:

actaully it should have been declare() - as I think the syntax for that
almost works already, but yes, code doesnt get compiled if it's inside a
block.

Regards
Alan

Zeev Suraski wrote:

At 03:57 26/05/2006, Alan Knowles wrote:

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

What's the semantics of that? The code inside doesn't get executed if
it's not the define()'d PHP version?

Zeev

Best regards,
Marcus

Best regards,
Marcus

19 years ago by Andi Gutmans — view source

unread

I think a preprocessor is one of the worst things that can ever happen to PHP.
It can be done as a Summer of Code project for academic reasons but I
would never be in favor of adding it to PHP. I think there's very
little use in a language like PHP and it will lead to the same
maintenance/debugging problems as with C.
If someone really needs a pre-processor then they should use it in
their private environment and can even use cpp if they want.
I can't believe Marcus that you are in favor of something like this.
In any case, it doesn't matter. Nothing can stop the student from
doing something like this and dumping it in pecl or something, but
I'd never want to see a pre-processor in PHP itself.

Andi

At 03:19 PM 5/26/2006, Marcus Boerger wrote:

Hello Zeev,

actually there was plenty of discussion prior to selecting the summer
of code projects. Nonetheless we will see how it will work out. For example
#line <num> <source> can easily be aded to the lexer already and doesn't
require a full blown preprocessor. Versioning is very different since it
should either be a real preprocessor and thus not doing any harm to php
or it is a language feature and then a bunch of stuff probably has to be
changed. Though maybe even then it is a simple additional state in the
lexer - those tools can be so easy.

Anyway you might want to contact the student.

marcus

Friday, May 26, 2006, 11:04:30 AM, you wrote:

Yeah I heard, but it doesn't mean it'll become a part of the language
(doesn't mean that it would not, but as usual, no discussion ;).

What Alan suggested is already a part of the language, bares no
additional overhead (both CPU cycles and brain cycles), and also
(least important point) is very easy to implement.

Zeev

At 05:08 26/05/2006, Marcus Boerger wrote:

Hello Zeev,

actually there is a student working on a pre-processor for his summer
of code project. And that will most likely cover versioning, too.

best regards
marcus

Friday, May 26, 2006, 4:06:00 AM, you wrote:

I read it as if it was declare() ;)

I agree with Pierre that the best way to handle BC break is not to
introduce it, but since that's not always 100% possible, this may
make sense. Of course, it'll only work with stuff that is
syntax-compliant with the currently running PHP version, but that
covers most BC breakage.

Zeev

At 04:57 26/05/2006, Alan Knowles wrote:

actaully it should have been declare() - as I think the syntax for that
almost works already, but yes, code doesnt get compiled if it's inside a
block.

Regards
Alan

Zeev Suraski wrote:

At 03:57 26/05/2006, Alan Knowles wrote:

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

What's the semantics of that? The code inside doesn't get
executed if
it's not the define()'d PHP version?

Zeev

Best regards,
Marcus

Best regards,
Marcus

19 years ago by Marcus Boerger — view source

unread

Hello Andi,

i for one think it might be a solution to at least lower the pain of
version differences. Which is the reason why i liked the proposal from
the beginning and took mentorship.

best regards
marcus

Sunday, May 28, 2006, 2:39:21 AM, you wrote:

I think a preprocessor is one of the worst things that can ever happen to PHP.
It can be done as a Summer of Code project for academic reasons but I
would never be in favor of adding it to PHP. I think there's very
little use in a language like PHP and it will lead to the same
maintenance/debugging problems as with C.
If someone really needs a pre-processor then they should use it in
their private environment and can even use cpp if they want.
I can't believe Marcus that you are in favor of something like this.
In any case, it doesn't matter. Nothing can stop the student from
doing something like this and dumping it in pecl or something, but
I'd never want to see a pre-processor in PHP itself.

Andi

At 03:19 PM 5/26/2006, Marcus Boerger wrote:

Hello Zeev,

actually there was plenty of discussion prior to selecting the summer
of code projects. Nonetheless we will see how it will work out. For example
#line <num> <source> can easily be aded to the lexer already and doesn't
require a full blown preprocessor. Versioning is very different since it
should either be a real preprocessor and thus not doing any harm to php
or it is a language feature and then a bunch of stuff probably has to be
changed. Though maybe even then it is a simple additional state in the
lexer - those tools can be so easy.

Anyway you might want to contact the student.

marcus

Friday, May 26, 2006, 11:04:30 AM, you wrote:

Yeah I heard, but it doesn't mean it'll become a part of the language
(doesn't mean that it would not, but as usual, no discussion ;).

What Alan suggested is already a part of the language, bares no
additional overhead (both CPU cycles and brain cycles), and also
(least important point) is very easy to implement.

Zeev

At 05:08 26/05/2006, Marcus Boerger wrote:

Hello Zeev,

actually there is a student working on a pre-processor for his summer
of code project. And that will most likely cover versioning, too.

best regards
marcus

Friday, May 26, 2006, 4:06:00 AM, you wrote:

I read it as if it was declare() ;)

I agree with Pierre that the best way to handle BC break is not to
introduce it, but since that's not always 100% possible, this may
make sense. Of course, it'll only work with stuff that is
syntax-compliant with the currently running PHP version, but that
covers most BC breakage.

Zeev

At 04:57 26/05/2006, Alan Knowles wrote:

actaully it should have been declare() - as I think the syntax for that
almost works already, but yes, code doesnt get compiled if it's inside a
block.

Regards
Alan

Zeev Suraski wrote:

At 03:57 26/05/2006, Alan Knowles wrote:

Can we start concentrating on finding a real solution to BC breaks
rather than throwing them out there and everyone complaining?

define(php5) {
stuff that breaks in php6
}
define(php6) {
stuff that doesnt work in PHP5
}

What's the semantics of that? The code inside doesn't get
executed if
it's not the define()'d PHP version?

Zeev

Best regards,
Marcus

Best regards,
Marcus

--

Best regards,
Marcus

19 years ago by Christian Schneider — view source

unread

Marcus Boerger wrote:

i for one think it might be a solution to at least lower the pain of
version differences. Which is the reason why i liked the proposal from
the beginning and took mentorship.

We don't need a full-blown preprocess for that. The much simpler version
switch proposed earlier would do. And this while introducing only 10% of
the debugging knightmares of a full preproc.

But then again I'm even wary of a version switch as it could lead to
code like

class A
{

declare(> php4)
{
static function foo() { ... }
}

declare(<= php4)
{
function foo() { ...}
}

}

which raises copy/paste issues.

I'd much rather see less incompatibilities introduced into PHP in an
attempt to make PHP a language is was never meant to be ;-)

Chris

19 years ago by Marcus Boerger — view source

unread

Hello Christian,

what you propose would mean a lot of changes to the php code and
and the zend engine. The pre processor to allow this will be written
as an extension and that extension will have no impact on anybody
that doens't like it simply becuase you can disable extensions.

best regards
marcus

Sunday, May 28, 2006, 10:01:58 AM, you wrote:

Marcus Boerger wrote:

i for one think it might be a solution to at least lower the pain of
version differences. Which is the reason why i liked the proposal from
the beginning and took mentorship.

We don't need a full-blown preprocess for that. The much simpler version
switch proposed earlier would do. And this while introducing only 10% of
the debugging knightmares of a full preproc.

But then again I'm even wary of a version switch as it could lead to
code like

class A
{

declare(> php4)
{
static function foo() { ... }
}

declare(<= php4)
{
function foo() { ...}
}

}

which raises copy/paste issues.

I'd much rather see less incompatibilities introduced into PHP in an
attempt to make PHP a language is was never meant to be ;-)

Chris

Best regards,
Marcus

19 years ago by William Candillon — view source

unread

I think that a macro will be a very nice and powerful solution to this
problem but according to me it needs to be done by an external tool.

Regards,

William

Hello Christian,

what you propose would mean a lot of changes to the php code and
and the zend engine. The pre processor to allow this will be written
as an extension and that extension will have no impact on anybody
that doens't like it simply becuase you can disable extensions.

best regards
marcus

Sunday, May 28, 2006, 10:01:58 AM, you wrote:

Marcus Boerger wrote:

i for one think it might be a solution to at least lower the pain of
version differences. Which is the reason why i liked the proposal from
the beginning and took mentorship.

We don't need a full-blown preprocess for that. The much simpler version
switch proposed earlier would do. And this while introducing only 10% of
the debugging knightmares of a full preproc.

But then again I'm even wary of a version switch as it could lead to
code like

class A
{

declare(> php4)
{
static function foo() { ... }
}

declare(<= php4)
{
function foo() { ...}
}

}

which raises copy/paste issues.

I'd much rather see less incompatibilities introduced into PHP in an
attempt to make PHP a language is was never meant to be ;-)

Chris

Best regards,
Marcus

--

--
William Candillon
Telecom Lille Student
E-mail: wcandillon@elv.enic.fr
Tel: +33(0) 6 67 99 13 16
CV: http://wcandillon.netcv.org
Resume: http://wcandillon.en.netcv.org

19 years ago by Christian Schneider — view source

unread

William Candillon wrote:

I think that a macro will be a very nice and powerful solution to this
problem but according to me it needs to be done by an external tool.

That already exists ;-)

Try
cpp -w -P -C <in.php >out.php 2>/dev/null
if you don't want to reinvent the wheel :-)

Marcus Boerger helly@php.net wrote:

what you propose would mean a lot of changes to the php code and
and the zend engine. The pre processor to allow this will be written
as an extension and that extension will have no impact on anybody
that doens't like it simply becuase you can disable extensions.

I'm all for making it an extension which is not included in the main
PHP. But your point is invalid because if a preprocessor can be done as
an extension then so can be my version: It is nothing but a very
stripped down preprocessor after all.

Anyway, I don't really care too much about how such a preprocessor is
done as long as a) it's not bundled with PHP by default and b) is not
used as an excuse to make incompatible syntax changes without compelling
reason.

Regards,

Chris

19 years ago by Markus Fischer — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Christian Schneider wrote:

William Candillon wrote:

I think that a macro will be a very nice and powerful solution to this
problem but according to me it needs to be done by an external tool.

That already exists ;-)

Try
cpp -w -P -C <in.php >out.php 2>/dev/null
if you don't want to reinvent the wheel :-)

That's really a very useful thing. I just want to mention that it may be
necessary to also use -traditional-cpp so white spaces don't get messed up.

- Markus
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.3 (MingW32)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEeqVm1nS0RcInK9ARAvw1AKCkRy0DcbWpZc1UWKqPCq9DtA7CaQCglHqc
+zre6WvuUGUMpszoEZpgdDU=
=AU8I
-----END PGP SIGNATURE

19 years ago by William Candillon — view source

unread

Try
cpp -w -P -C <in.php >out.php 2>/dev/null
if you don't want to reinvent the wheel :-)

It's very limited! It's not implementing #line macro for php by example.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Christian Schneider wrote:

William Candillon wrote:

I think that a macro will be a very nice and powerful solution to this
problem but according to me it needs to be done by an external tool.

That already exists ;-)

Try
cpp -w -P -C <in.php >out.php 2>/dev/null
if you don't want to reinvent the wheel :-)

That's really a very useful thing. I just want to mention that it may be
necessary to also use -traditional-cpp so white spaces don't get messed up.

Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEeqVm1nS0RcInK9ARAvw1AKCkRy0DcbWpZc1UWKqPCq9DtA7CaQCglHqc
+zre6WvuUGUMpszoEZpgdDU=
=AU8I
-----END PGP SIGNATURE-----

--

--
William Candillon
Telecom Lille Student
E-mail: wcandillon@elv.enic.fr
Tel: +33(0) 6 67 99 13 16
CV: http://wcandillon.netcv.org
Resume: http://wcandillon.en.netcv.org

19 years ago by Marcus Boerger — view source

unread

Hello Christian,

first of all c would be enough. Preprocessing has nothing to do with c++.
Also a lot of compilers allow to use the pre-process stand alone. And then
there is this one little disadvantage. A c compiler doesn't know that it
is not supposed to deal with stuff outside <?php...?> and last but not
least loading a c compiler is not always possible...since it would allow
to use it, which is potentially dangerous. And at last it takes forever
having to load a c compiler everytime you want a php script preprocessed.

best regards
marcus

Sunday, May 28, 2006, 8:26:57 PM, you wrote:

William Candillon wrote:

I think that a macro will be a very nice and powerful solution to this
problem but according to me it needs to be done by an external tool.

That already exists ;-)

Try
cpp -w -P -C <in.php >out.php 2>/dev/null
if you don't want to reinvent the wheel :-)

Marcus Boerger helly@php.net wrote:

what you propose would mean a lot of changes to the php code and
and the zend engine. The pre processor to allow this will be written
as an extension and that extension will have no impact on anybody
that doens't like it simply becuase you can disable extensions.

I'm all for making it an extension which is not included in the main
PHP. But your point is invalid because if a preprocessor can be done as
an extension then so can be my version: It is nothing but a very
stripped down preprocessor after all.

Anyway, I don't really care too much about how such a preprocessor is
done as long as a) it's not bundled with PHP by default and b) is not
used as an excuse to make incompatible syntax changes without compelling
reason.

Regards,

Chris

Best regards,
Marcus

19 years ago by Zeev Suraski — view source

unread

At 04:03 28/05/2006, Marcus Boerger wrote:

Hello Andi,

i for one think it might be a solution to at least lower the pain of
version differences.

It does look like a clear example of shooting one's head off over a
headache :) What Alan suggested does the job equally well without
complicating the language any further one bit.

Zeev

19 years ago by Derick Rethans — view source

unread

This situation is just like the one where we had to fix reference stuff
as we found out that it indeed was causing SEGVs in certain situations.
And i want to provide such situations and i want that at nearly all
costs because i do not want to have such a situation again. For one
reason it took me like a full week of work to help Derick with a tiny
piece in debugging and i don't know how much time Derick spend on
tracking the issue down and fixing it. In short i rather drop a feature
than risking SEGVs.

A few weeks I would say :)

Now decide for your self what is more expensive/more dangerous for you?
An unstablel PHP or a tiny feature loss?

Btw, right now you can have abstract static methods in interfaces. This
was a compromise I introduced when we found out the issue.

Did I miss something here? I thought that a patch of yours made this a
fatal error? Did you revert this?

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

19 years ago by Daniel Convissor — view source

unread

<?php
class TheParent {
public $x = 3;
}
class UglyUncle {
function f() {
$this->x = 5;
}
}
class Child extends TheParent {
function f() {
UglyUncle::f();
}
}
$c = new Child();
var_dump($c->x);
$c->f();
var_dump($c->x);
?>
--EXPECT--
int(3)
int(5)

"Ugly" is right. As far as I'm concerned, that code should never have
worked in the first place.

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

19 years ago by Marcus Boerger — view source

unread

Hello Todd,

code like this is actually exactly what i mean. It is completley broken
design, maybe not for you of course. But according to any oo guideline.
But that's a different story. The real problem is that this behavior is
based on or worked around some behavior in the engine that is sooner or
later most likely to cause severs SEGVs.

best regards
marcus

Wednesday, May 24, 2006, 8:56:06 PM, you wrote:

In php5 this works even without an instanceof relationship.
(I'm running 5.1.2 and this test gets a "PASS" from run-tests.php.)
I know the following test case does not even remotely follow
good OO design principles, but it's hard to imagine us going
back to the drawing board with our app. Please don't break
the following in php6 just to teach me a lesson about OO design.

If there's a repository of "someone will complain about a BC
break if this changes" tests, please add the following:

--TEST--
test that $this survives in a semi-static call
--FILE--
<?php
class TheParent {
public $x = 3;
}
class UglyUncle {
function f() {
$this->x = 5;
}
}
class Child extends TheParent {
function f() {
UglyUncle::f();
}
}
$c = new Child();
var_dump($c->x);
$c->f();
var_dump($c->x);
?>>
--EXPECT--
int(3)
int(5)

Thanks,
Todd

I don't see why it has to be a fatal error. If there's an instanceof
relationship we can keep $this. If not, we should not pass $this
(which I believe we already do in PHP 5), in which case the author
would have to pass $this if he wants to change public properties.

Andi

At 12:49 PM 5/15/2006, Edin Kadribasic wrote:

Todd Ruth wrote:

I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.

My sentiments exactly. OO purity/strictness do now work well with
PHP's main strength -- its dynamicity.

Edin

--

Best regards,
Marcus

19 years ago by Stanislav Malyshev — view source

unread

MB>>> I know the following test case does not even remotely follow
MB>>> good OO design principles, but it's hard to imagine us going
MB>>> back to the drawing board with our app. Please don't break
MB>>> the following in php6 just to teach me a lesson about OO design.

That's not about some abstract design principles - it's just a bug in OO
implementation, static call should not leave $this from previous context
dangling. Of course it's unlpleasant to find your code to rely on buggy
behaviour, but bugs need to be fixed anyway. There's no single reason I
can imagine why "$this" in context of static call should mean "the object
we used last time on the stack where we had member function call". That's
just not right.

MB>>> test that $this survives in a semi-static call

What on earth "semi-static" could mean???

Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

19 years ago by Christian Schneider — view source

unread

Stanislav Malyshev wrote:

That's not about some abstract design principles - it's just a bug in OO
implementation, static call should not leave $this from previous context
dangling. Of course it's unlpleasant to find your code to rely on buggy

While that might be true it does not mean that we have to force a 100%
separation between static and non-static methods. It would be very
PHP-like to allow

class URL
{
function get($url = null)
{
if (!isset($url))
$url = $this->url;
...
}
}

which could throw an error if $this is used when called statically but
still allows the polymorphism of $url->get(); and URL::get("php.net");
which can be very handy in utility classes/functions.

While this is not the most crucial of all concepts I still think it is
closer to the strength, dynamicity and opiniatedness of PHP than
enforcing the keyword static and introducing sort of a strong typing
through the backdoor.

My $.02,

Chris, follower of the minimalistic-OO school

19 years ago by Marcus Boerger — view source

unread

Hello Andi,

passing $this to a static function is a different set of problems calling
trouble on another front. If you pass $this to a static function you sooner
or later pass it as $this and sooner or later you call back into the object
scope from that $this. Now the trouble is that suddenly we have two $this.
The obejct $this which is a pseudo variable controlled by the engine and
which cannot be overwritten and $this in the local symbol table. The one
that can be changed and even unset. I am quite sure the engine is not
designed to take care for this situations in all places. That said sooner
or later the same people complaining now will shout at us: hey you stuff
sucks - fix it.

marcus

Tuesday, May 16, 2006, 4:41:33 AM, you wrote:

I don't see why it has to be a fatal error. If there's an instanceof
relationship we can keep $this. If not, we should not pass $this
(which I believe we already do in PHP 5), in which case the author
would have to pass $this if he wants to change public properties.

Andi

At 12:49 PM 5/15/2006, Edin Kadribasic wrote:

Todd Ruth wrote:

I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.

My sentiments exactly. OO purity/strictness do now work well with
PHP's main strength -- its dynamicity.

Edin

--

Best regards,
Marcus

19 years ago by Marcus Boerger — view source

unread

Hello Greg,

Monday, May 15, 2006, 12:51:16 PM, you wrote:

Steph Fox wrote:

Marcus,

FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
switched on anywhere but a dev box? - and when there is the option to
switch on E_ALL without E_STRICT, it makes it much easier to miss
useful information about the direction PHP is going in.

Pierre: the biggest E_STRICT issues I'm aware of are the 'vars don't
live here any more' one (which was removed two months ago in PHP_5_1
branch) and the 'only variables can be passed by reference' one (which
is in PHP 4.4.* anyway). Beyond those two, it ought to be pretty rare

Side note: calling functions statically that do not have a static
modifier causes E_STRICT. Hello PEAR::isError()

This is of course going to be a fatal in PHP 6, but it is now the most
common E_STRICT I see in PHP4-based code.

I agree that it is appropriate to change something like this in a 5.X.0,
but it will be a headache for anyone running legacy apps (not just
PEAR). Until someone writes some killer apps in PHP5 to replace phpBB
and company, changes of this nature will simply prevent moving to PHP5
but that's another story and not the concern of internals (I agree with
this strongly). If you all are willing to deal with the fallout (think
PHP 4.4) then that's that.

Ones again E_ALL is for development. For example to move PEAR code to PHP 5.
It is not for running legacy apps. IF you guys want i'd be ok with adding a
new mode say "E_RUN"...

Best regards,
Marcus

19 years ago by Steph Fox — view source

unread

Ones again E_ALL is for development. For example to move PEAR code to PHP

It is not for running legacy apps. IF you guys want i'd be ok with adding
a
new mode say "E_RUN"...

You think that - I think that. After Brian Moon's response I went and
checked what the INI files distributed with PHP actually say.

ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL

I'd guess that's why Brian reports seeing E_ALL enabled on web hosts;
they're advised to use the settings in ini-recommended, after all.

(No I don't think we need E_RUN - we just need to rethink this.)

Steph

19 years ago by Brian Moon — view source

unread

Steph Fox wrote:

ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL

I'd guess that's why Brian reports seeing E_ALL enabled on web hosts;
they're advised to use the settings in ini-recommended, after all.

Perhaps there should be an ini-development and an ini-production.

--

Brian Moon

http://dealnews.com/
Its good to be cheap =)

19 years ago by Marcus Boerger — view source

unread

Hello Brian,

yeah we should simply rename the two files we have right now to that.
I never knew which one to take since their names are not helpful.
In production we would set something like E_ALL & ~E_STRICT & ~E_NOTICE.
While in development we would do E_ALL as in all.

Nice idea!

best regards
marcus

Monday, May 15, 2006, 8:49:11 PM, you wrote:

Steph Fox wrote:

ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL

I'd guess that's why Brian reports seeing E_ALL enabled on web hosts;
they're advised to use the settings in ini-recommended, after all.

Perhaps there should be an ini-development and an ini-production.

--

Brian Moon

http://dealnews.com/
Its good to be cheap =)

Best regards,
Marcus

19 years ago by Brian Moon — view source

unread

Marcus Boerger wrote:

Hello Brian,

yeah we should simply rename the two files we have right now to that.
I never knew which one to take since their names are not helpful.
In production we would set something like E_ALL & ~E_STRICT & ~E_NOTICE.
While in development we would do E_ALL as in all.

Of course, in reference to my earlier comments, this will mean that
there is a high probablity the casual PHP user that does not run his
server will never see the E_STRICT stuff until PHP6.

Unfortunately, I can see no way around it.

--

Brian Moon

http://dealnews.com/
Its good to be cheap =)

19 years ago by Richard Lynch — view source

unread

yeah we should simply rename the two files we have right now to
that.
I never knew which one to take since their names are not helpful.
In production we would set something like E_ALL & ~E_STRICT &
~E_NOTICE.
While in development we would do E_ALL as in all.

Personally, I've always thought that a smarter setup is to keep E_ALL
on all the time, and just turn display_errors off in production, and
logging on as an optional in production...

But that presumes a quality level in PHP code that's not "out there"
yet -- partially because E_ALL wasn't the default for sooooo long, so
we had a zillion E_NOTICE messages going un-noticed by the bulk of
users.

If your production PHP code is generating so many entires in a log
file that it's a problem for the log file size, then, really, you've
got much bigger problems than the log file size...

I can see having the logging off for performance in specific
situations, but that would be the people who REALLY know what they're
doing anyway.

The naive webhost trying to scratch a living out of installing PHP
with the default settings and is happy if "it works" is the target
audience for the php.ini-recommended -- not the expert than could
probably write php.ini from scratch for the settings they care about.

YMMV

--
Like Music?
http://l-i-e.com/artists.htm

19 years ago by Brian Moon — view source

unread

If your production PHP code is generating so many entires in a log
file that it's a problem for the log file size, then, really, you've
got much bigger problems than the log file size...

At dealnews, we have been using PHP since PHP/FI. We have written A LOT
of code that never expected E_NOTICE to be on. While we strive to write
new code in such a way that E_NOTICE would not be a problem (I have
gotten used to writing Phorum that way), we do not enable it on our dev
machines or production machines due to legacy code. Perhaps when we can
make money rewriting all our code from scratch we will look into it. ;)

--

Brian Moon

http://dealnews.com/
Its good to be cheap =)

19 years ago by Andi Gutmans — view source

unread

At 11:49 AM 5/15/2006, Brian Moon wrote:

Steph Fox wrote:

ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL
I'd guess that's why Brian reports seeing E_ALL enabled on web
hosts; they're advised to use the settings in ini-recommended, after all.

Perhaps there should be an ini-development and an ini-production.

"recommended" was born after "dist" because we wanted to show how to
run PHP correctly (esp. BC breaking INI parameters such as
register_globals=off which are recommended). It's a bit different
from development vs. production which I agree would be very helpful.
Question is how do we do it? Do we abandon the former for the latter,
or is there a way to solve all at once? :)

Andi

19 years ago by Steph Fox — view source

unread

At 11:49 AM 5/15/2006, Brian Moon wrote:

Perhaps there should be an ini-development and an ini-production.

"recommended" was born after "dist" because we wanted to show how to run
PHP correctly (esp. BC breaking INI parameters such as
register_globals=off which are recommended). It's a bit different from
development vs. production which I agree would be very helpful. Question
is how do we do it? Do we abandon the former for the latter, or is there a
way to solve all at once? :)

Andi, if you go back and actually read those files they claim to be 'default
settings' and 'production settings' respectively. I agree the whole idea of
'default settings' should be dropped (in this sense), but I think you'll
find most people out there take those directives as 'how PHP should be
used'. To me it's a tad worrying - given that context - that the
error_reporting recommendations are as they are.

Since both files are being, if you like, 'marketed' in the way Brian
mentioned, it might be a good time to a) rename them in the way he suggested
and b) go through those settings with a fine-toothed comb before doing so.

Just an opinion, of course...

Steph

19 years ago by Hannes Magnusson — view source

unread

Ones again E_ALL is for development. For example to move PEAR code to PHP

It is not for running legacy apps. IF you guys want i'd be ok with adding
a
new mode say "E_RUN"...

You think that - I think that. After Brian Moon's response I went and
checked what the INI files distributed with PHP actually say.

ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL
display_errors is however Off in -recommended so it shouldnt matter
for those who use it...

-Hannes

19 years ago by Jasper Bryant-Greene — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Steph Fox wrote:

Ones again E_ALL is for development. For example to move PEAR code to
PHP 5.
It is not for running legacy apps. IF you guys want i'd be ok with
adding a
new mode say "E_RUN"...

You think that - I think that. After Brian Moon's response I went and
checked what the INI files distributed with PHP actually say.

ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL

I'd guess that's why Brian reports seeing E_ALL enabled on web hosts;
they're advised to use the settings in ini-recommended, after all.

I see nothing wrong with E_ALL enabled on a production web server - I
administer a very busy web server running a large PHP application, and
have error_reporting set to E_ALL | E_STRICT.

Of course, I do not have display_errors on. Pretty much the only errors
I ever get logged are from PEAR, and I have a system to strip these out
at the logger level.

Jasper
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaOvYFfAeHhDzT4gRA2QUAJ9ERKmtU7fpGcKmbvzOiZSqnTr1pQCcC3S2
trR/ddzI0bZfmyfmZN0ET1w=
=m6k4
-----END PGP SIGNATURE

19 years ago by Markus Fischer — view source

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcus Burger wrote:

Ones again E_ALL is for development.

Is this the statement of all developers or only yours?

I have to enable E_ALL on live servers (display_errors to 0), because
whatever resource you have at your hand, you just can't make sure that
all code paths work properly with all the possible user inputs. It's
just not possible.

So by logging E_ALL and trying to monitor the log regularly is the only
change to spot problems.

I would go crazy and have no sleep anymore if I wouldn't do that because
I would have no feedback at all how our application performs. You can't
just sit and wait for user bug reports.

- Markus
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.2.2 (MingW32)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEaNC01nS0RcInK9ARAq/3AKDF4hQto1TeVzE/VRi0j54/Dg9kUwCgwO8q
CyR2MtSqWdF+HBMp2Y9cV1Y=
=gOMf
-----END PGP SIGNATURE

19 years ago by Marcus Boerger — view source

unread

Hello Markus,

Monday, May 15, 2006, 9:04:20 PM, you wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcus Burger wrote:

Ones again E_ALL is for development.

Is this the statement of all developers or only yours?

Probably mine, I mean i can only speak for myself here.

I have to enable E_ALL on live servers (display_errors to 0), because
whatever resource you have at your hand, you just can't make sure that
all code paths work properly with all the possible user inputs. It's
just not possible.

This is very true, yet i don't see a reason to include E_NOTICE and E_STRICT
on a production machine.

Best regards,
Marcus

19 years ago by Richard Lynch — view source

unread

This is very true, yet i don't see a reason to include E_NOTICE and
E_STRICT
on a production machine.

You've got 100% code coverage with all possible inputs and boundary
conditions in your QA process?...

Cuz, if not, I really don't see why you'd turn these OFF...

Unless, like, you actually send code of to production complete with
un-debugged E_NOTICE and E_STRICT messages that would flood your log
files... [shrug]

At that point, I'd say "logrotate more often" before I'd say turn off
E_NOTICE or E_STRICT.

Maybe I'm just naive...

--
Like Music?
http://l-i-e.com/artists.htm

19 years ago by Brian Moon — view source

unread

Why would anyone have E_ALL
switched on anywhere but a dev box?

Working with Phorum, I get to peer into lots of different hosting
companies setups when helping my users. I have seen many hosts that do
have E_ALL enabled and do not log errors because they have no way to
provide that log back to their users. Nor would the users have a
comprehension of the error log.

For the enterprise, I would believe that nearly all production servers
shield error output from web pages in one way or another. However, I
believe that PHP has its roots in the small web site. If you start
making it hard on them to upgrade, you will see hosts that never upgrade
their PHP versions.

--

Brian Moon

http://dealnews.com/
Its good to be cheap =)

19 years ago by Steph Fox — view source

unread

Why would anyone have E_ALL switched on anywhere but a dev box?

Working with Phorum, I get to peer into lots of different hosting
companies setups when helping my users. I have seen many hosts that do
have E_ALL enabled and do not log errors because they have no way to
provide that log back to their users. Nor would the users have a
comprehension of the error log.

For the enterprise, I would believe that nearly all production servers
shield error output from web pages in one way or another. However, I
believe that PHP has its roots in the small web site. If you start making
it hard on them to upgrade, you will see hosts that never upgrade their
PHP versions.

That should be as simple as explicitly offering

;E_ALL & ~E_STRICT

in the php.ini (and of course in the upgrade notes too). PHP 5 has been out
there for 2 years now, I find it hard to believe that anyone involved - host
or user - isn't aware that E_STRICT is on its way. Greg wrote earlier that
the biggest issue PEAR has with E_STRICT nowadays comes when non-declared
statics are called. Seriously, people writing that kind of code aren't
likely to be naive users.

I think it's going to be far worse if code that runs cleanly under PHP 4
throws a fatal error in PHP 6 with no mention of it being problematic in
between!

Steph

19 years ago by Brian Moon — view source

unread

I find it hard to believe that anyone
involved - host or user - isn't aware that E_STRICT is on its way.

Honestly, I only heard about it in the last few weeks. And I run an
open source project based on PHP. I do PHP for a living. The average
web host and/or webmaster does not keep up with the future changes of PHP.

You really give web hosts too much credit. They will move from Fedora
Core 1 to some distro that has PHP 6 on it directly. They don't update
PHP along the way.

I am not saying I like this or that it is good. I am saying that this
is the way things are. If you want to ignore these users, that is fine.
But, I just don't want rose colored glasses making you believe that
everyone that uses PHP knows what is happening to PHP.

--

Brian Moon

http://dealnews.com/
Its good to be cheap =)

19 years ago by Marcus Boerger — view source

unread

Hello Brian,

Monday, May 15, 2006, 6:40:58 PM, you wrote:

I find it hard to believe that anyone
involved - host or user - isn't aware that E_STRICT is on its way.

Honestly, I only heard about it in the last few weeks. And I run an
open source project based on PHP. I do PHP for a living. The average
web host and/or webmaster does not keep up with the future changes of PHP.

That's exactly the point why we should enable it. Now and not in PHP 9.

Best regards,
Marcus

19 years ago by Richard Lynch — view source

unread

Why would anyone have E_ALL
switched on anywhere but a dev box?

Working with Phorum, I get to peer into lots of different hosting
companies setups when helping my users. I have seen many hosts that
do
have E_ALL enabled and do not log errors because they have no way to
provide that log back to their users. Nor would the users have a
comprehension of the error log.

For the enterprise, I would believe that nearly all production servers
shield error output from web pages in one way or another. However, I
believe that PHP has its roots in the small web site. If you start
making it hard on them to upgrade, you will see hosts that never
upgrade
their PHP versions.

A quick Google for common PHP error messages will almost for sure find
you a zillion sites with E_ALL in production servers.

I'm not saying it's the Right Way to do things -- I'm saying it's the
way a LOT of hosts are set up by default, and their users don't know
how to change it, or don't consider the security implications serious
enough.

--
Like Music?
http://l-i-e.com/artists.htm

19 years ago by Brian Moon — view source

unread

A quick Google for common PHP error messages will almost for sure find
you a zillion sites with E_ALL in production servers.

2.1 million in fact.

http://www.google.com/search?q=notice+undefined+php

--

Brian Moon

http://dealnews.com/
Its good to be cheap =)

19 years ago by Sebastian Mendel — view source

unread

Steph Fox schrieb:

Marcus,

FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
switched on anywhere but a dev box?

at least i, as no one on this mailing list is interested in me, but i
have it on and it is logged only and not displayed.

some bugs are really hard to find, cause it is not always possible to
test every aspect of an application - it is a dream to think you can get
you application absolutely error free and failsafe - and how would you
recognize errors your customers get if you not enable error reporting?

you could say E_ERROR or E_WARNING would be enough but some logical
errors throw only E_NOTICE if they throw any error at all ...

--
Sebastian

19 years ago by Pierre — view source

unread

On Sun, 14 May 2006 20:59:03 +0200
helly@php.net (Marcus Boerger) wrote:

Now the idea of E_STRICT is that core developers can inform users
about changes in upcoming versions of php as early as possible. So
developers should have E_ALL including E_STRICT enabled during
development so that they are able to develop clean applications that
most likely will work in the next version. On the production machines
you would still either not use E_ALL or log only and don't show the
errors in the application.

Sorry but I do not buy these arguments. As it is clear than nobody
should have display_errors On on a production servers, that does not
mean we can do that. I see it as a breakage.

That said i am about to not remove E_STRICT from E_ALL and MFH the php
6.0 to item just now.
See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE
(dmitry))

It was planed for 6.0 for a good reason. 5.1.x is dead, but we are
fixing many issues (including security problems) in 5.2.x, many people
will not update because of the "breakages". I see that as a strategic
mistake.

Since this is for the benefit of the users to prevent issues with
changes in behavior from my opinion it is best to do this behavior
change as early as possible, which is in my opinion 5.2 anyway.

On the other side it is for the benefit of our users to prevent
breakages and useless annoyances.

That said i'll let it in and if there is no valid argument against, i
will put it into the NEWS file and the newly started
README.UPDATE_5_2.

I already asked you (without answer) to tell me which cases you
consider critical and thus should be moved to E_ALL. Which are they?

-- Pierre

19 years ago by Marcus Boerger — view source

unread

Hello Pierre,

Monday, May 15, 2006, 2:39:02 AM, you wrote:

On Sun, 14 May 2006 20:59:03 +0200
helly@php.net (Marcus Boerger) wrote:

That said i am about to not remove E_STRICT from E_ALL and MFH the php
6.0 to item just now.
See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE
(dmitry))

It was planed for 6.0 for a good reason. 5.1.x is dead, but we are
fixing many issues (including security problems) in 5.2.x, many people
will not update because of the "breakages". I see that as a strategic
mistake.

You are speaking of PHP 4 people here.

Since this is for the benefit of the users to prevent issues with
changes in behavior from my opinion it is best to do this behavior
change as early as possible, which is in my opinion 5.2 anyway.

On the other side it is for the benefit of our users to prevent
breakages and useless annoyances.

If you don't like E_STRICT you can simply set E_ALL without it in your
ini, stay with a version of your likes as Steph suggested and live happily
ever after.

That said i'll let it in and if there is no valid argument against, i
will put it into the NEWS file and the newly started
README.UPDATE_5_2.

I already asked you (without answer) to tell me which cases you
consider critical and thus should be moved to E_ALL. Which are they?

Critical? I said that any changes that have a behavior impact should be
documented. I hope i didn't miss anything besides E_STRICT which faith
hasn't been decided yet.

But guess what, you're more then welcome to update and write additions
to the update file instead of only complaining.

Best regards,
Marcus

19 years ago by Derick Rethans — view source

unread

That said i am about to not remove E_STRICT from E_ALL and MFH the php
6.0 to item just now.
See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry))

Since this is for the benefit of the users to prevent issues with
changes in behavior from my opinion it is best to do this behavior
change as early as possible, which is in my opinion 5.2 anyway.

That said i'll let it in and if there is no valid argument against, i
will put it into the NEWS file and the newly started README.UPDATE_5_2.

Yup, I agree on this.

regards,
Derick

19 years ago by Lukas Smith — view source

unread

Derick Rethans wrote:

That said i am about to not remove E_STRICT from E_ALL and MFH the php
6.0 to item just now.
See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry))

Since this is for the benefit of the users to prevent issues with
changes in behavior from my opinion it is best to do this behavior
change as early as possible, which is in my opinion 5.2 anyway.

That said i'll let it in and if there is no valid argument against, i
will put it into the NEWS file and the newly started README.UPDATE_5_2.

Yup, I agree on this.

The key point is that with reading the upgrading guide people will know
howto get the old behavior. I do not quite agree that this change is
necessary, but I guess the "ALL" in "E_ALL" implies it includes
everything, so its logical on that level.

regards,
Lukas

PS: Obviously this will be quite painful for PEAR, but I guess that is
partially the point here: create some pains to nudge people towards
writing PHP5 only code. Or maybe its just about covering our asses
against users who complain about us removing deprecated functionality
after a few minor releases.

19 years ago by Marcus Boerger — view source

unread

Hello Lukas,

Monday, May 15, 2006, 8:43:41 AM, you wrote:

Derick Rethans wrote:

That said i am about to not remove E_STRICT from E_ALL and MFH the php
6.0 to item just now.
See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_ALL DONE (dmitry))

Since this is for the benefit of the users to prevent issues with
changes in behavior from my opinion it is best to do this behavior
change as early as possible, which is in my opinion 5.2 anyway.

That said i'll let it in and if there is no valid argument against, i
will put it into the NEWS file and the newly started README.UPDATE_5_2.

Yup, I agree on this.

The key point is that with reading the upgrading guide people will know
howto get the old behavior. I do not quite agree that this change is
necessary, but I guess the "ALL" in "E_ALL" implies it includes
everything, so its logical on that level.

regards,
Lukas

PS: Obviously this will be quite painful for PEAR, but I guess that is
partially the point here: create some pains to nudge people towards
writing PHP5 only code. Or maybe its just about covering our asses
against users who complain about us removing deprecated functionality
after a few minor releases.

Sorry i have to say that but PEAR is no argument here as still after
years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing
a PHP 5 version here.

Best regards,
Marcus

19 years ago by Lukas Smith — view source

unread

Marcus Boerger wrote:

<offtopic> > Sorry i have to say that but PEAR is no argument here as still after > years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing > a PHP 5 version here.

PEAR is PHP5 compatible. But you probably meant E_STRICT compatible.
Yes, I agree that PEAR needs to become once again a place for features
missing in PHP and not a place for legacy code.
</offtopic>

Anyways I brought up PEAR more as an example of what our current
userbase looks like. Mostly doing PHP4 and where its PHP5 its often
written to also be compatible with PHP4. By increasing the burden on
keeping this "duality" we might get more people to make the jump which
might put enough pressure on hosters to finally break the chicken and
egg situation with PHP5.

regards,
Lukas

19 years ago by Ron Korving — view source

unread

Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code,
where PHP5 features will actually be used and backwards compatibility for
PHP4 is lacking. The current PEAR could gradually be ported into this, and
PHP4-users can continue to use PEAR (version 1, if you will).

Ron

"Lukas Smith" lsmith@php.net schreef in bericht
news:44682CC8.6010200@php.net...

Marcus Boerger wrote:
<offtopic> > Sorry i have to say that but PEAR is no argument here as still after > years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing > a PHP 5 version here.
PEAR is PHP5 compatible. But you probably meant E_STRICT compatible. Yes,
I agree that PEAR needs to become once again a place for features missing
in PHP and not a place for legacy code.
</offtopic>

Anyways I brought up PEAR more as an example of what our current userbase
looks like. Mostly doing PHP4 and where its PHP5 its often written to also
be compatible with PHP4. By increasing the burden on keeping this
"duality" we might get more people to make the jump which might put enough
pressure on hosters to finally break the chicken and egg situation with
PHP5.

regards,
Lukas

19 years ago by Lukas Smith — view source

unread

Ron Korving wrote:

Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code,
where PHP5 features will actually be used and backwards compatibility for
PHP4 is lacking. The current PEAR could gradually be ported into this, and
PHP4-users can continue to use PEAR (version 1, if you will).

Maybe. But this is a topic for another list ..

regards,
Lukas

19 years ago by Pierre — view source

unread

Sorry i have to say that but PEAR is no argument here as still after
years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing
a PHP 5 version here.

This is a pointless argument. First there is php5 only packages.

Second you are proposing to change behaviors between two minor
releases. This is not something I would like to see in 5.2. It was
planed to be done in php 6.0. Your mistake is not a reason to change
this plan.

--Pierre