Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » forward compatibility "public" in 4.4 »

forward compatibility "public" in 4.4

php.internals

Lukas Smith

21 years ago
Hi, A while ago someone on IRC suggested that it might be a good idea to add "public" to PHP 4.x for forward compatibility. I brought it up again on IRC yesterday and several prominent members of the php core community said it would be a good idea to add to the 4.4 branch. The patch seems to be a 3 liner in the zend_language_scanner.l file. Atleast that worked for me. Maybe there is a better/cleaner solution, but either way its not going to have drastic technical implications. Its mainly a political decision to make. I think its a good idea to have, to make it somewhat possible to prepare for the PHP5 E_STRICT world, while still developing PHP4 compatible code. I could for example see this help increase the PHP5 adoption inside PEAR, since this would allow us to make some packages E_STRICT compatible without throwing out PHP4 compatibility (inside PEAR we consider increased major PHP versions to be a BC break, but not minor versions). regards, Lukas

Ilia A.

21 years ago
+1. The patch is actually a one liner :) -<ST_IN_SCRIPTING>"var" { +<ST_IN_SCRIPTING>("var"|"public") { Ilia

Stanislav Malyshev

21 years ago
LS>> LS>>A while ago someone on IRC suggested that it might be a good idea to add LS>>"public" to PHP 4.x for forward compatibility. I brought it up again on IRC LS>>yesterday and several prominent members of the php core community said it LS>>would be a good idea to add to the 4.4 branch. Why it would be a good idea? You couldn't run this code on 4.x{x<4} anymore. And you still don't have php5 capabilities. So you get PHP code which has all PHP 4 restrictions plus is not portable to arbitrary PHP 4 version and requires only php 4.4 to run. How is it good? LS>>I think its a good idea to have, to make it somewhat possible to prepare for LS>>the PHP5 E_STRICT world, while still developing PHP4 compatible code. I LS>>could for example see this help increase the PHP5 adoption inside PEAR, Like, PEAR would drop support for PHP 4.3 or it would have two copies of the code - one with public keyword and one without?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Lukas Smith

21 years ago
Stanislav Malyshev wrote:
> LS>>I think its a good idea to have, to make it somewhat possible to prepare for > LS>>the PHP5 E_STRICT world, while still developing PHP4 compatible code. I > LS>>could for example see this help increase the PHP5 adoption inside PEAR, > > Like, PEAR would drop support for PHP 4.3 or it would have two copies of > the code - one with public keyword and one without?
Currently PEAR.php requires PHP 4.2. We could eventually (as an intermediate step) move this dep to 4.4, not immediatly. However currently there is a strong trend to create new versions of packages for the main reason of making them E_STRICT compatible. However lets not get too far into the PEAR politics here ;-) Anyways I just wanted to give this as an example. I think its much more useful for independent developers who have more control over their user setups than PEAR. This allows them to make the move less painful and therefore will facilitate rather than prolong the move to PHP5 (which is a good thing). regards, Lukas

Stanislav Malyshev

21 years ago
LS>>Currently PEAR.php requires PHP 4.2. This means there are a lot of people using PEAR with PHP 4.3 and 4.2. And there's almost no people using it with 4.4 - since 4.4 is not out. So now you want to go out and tell them "upgrade your hosting to our brand-new PHP version risking breaking existing apps - or lose PEAR. And it's all because we want a fancy keyword". Not a good message for a package that should be to PHP something like libc is to C, I think. LS>>Anyways I just wanted to give this as an example. I think its much LS>>more useful for independent developers who have more control over LS>>their user setups than PEAR. This allows them to make the move less LS>>painful and therefore will facilitate rather than prolong the move to LS>>PHP5 (which is a good thing). I wonder what was the original purpose of PHP5 emitting warning when seeing 'var'? What are you basically saying now is "I want PHP4 code that wouldn't have messages on my class vars if run in PHP5". But I'm sure there was some idea behind these warnings, not?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Gareth Ardron

21 years ago
Stanislav Malyshev wrote:
>LS>>Currently PEAR.php requires PHP 4.2. > >This means there are a lot of people using PEAR with PHP 4.3 and 4.2. And >there's almost no people using it with 4.4 - since 4.4 is not >out. So now you want to go out and tell them "upgrade your hosting to our >brand-new PHP version risking breaking existing apps - or lose PEAR. And >it's all because we want a fancy keyword". Not a good message for a >package that should be to PHP something like libc is to C, I think. > >
I didn't read it as being suggested that the php dependancy for pear was bumped up to 4.4 as soon as 4.4 was released - indeed, that would be a mind-numbingly stupid idea. But as bug fixes are still coming out for the 4.x branch, why not bump up the required pear number to 4.4 in say, 6 months time or something - thereby giving users the time and enough warning to upgrade.

Lukas Smith

21 years ago
Stanislav Malyshev wrote:
> I wonder what was the original purpose of PHP5 emitting warning when > seeing 'var'? What are you basically saying now is "I want PHP4 code that > wouldn't have messages on my class vars if run in PHP5". But I'm sure > there was some idea behind these warnings, not?
There was a reason. So that people who mark things "var" because there was no true PPP available will be notified that they are using deprecated syntax. To quote Andi "It was meant to help people find var's so that they can be explicit about the access modifiers." So to me it seems if I have no private/protected, but only public properties I would like to be able to preempt a needless warning as I migrade to PHP5. I dont agree however we should make protected and private simply behave as var in PHP 4.x as this would indeed just undermine the entire point of the E_STRICT warning. regards, Lukas

Andrey Hristov

21 years ago
Lukas Smith wrote:
> Stanislav Malyshev wrote: > >> I wonder what was the original purpose of PHP5 emitting warning when >> seeing 'var'? What are you basically saying now is "I want PHP4 code >> that wouldn't have messages on my class vars if run in PHP5". But I'm >> sure there was some idea behind these warnings, not? > > > There was a reason. So that people who mark things "var" because there > was no true PPP available will be notified that they are using > deprecated syntax. To quote Andi "It was meant to help people find var's > so that they can be explicit about the access modifiers." > > So to me it seems if I have no private/protected, but only public > properties I would like to be able to preempt a needless warning as I > migrade to PHP5. > > I dont agree however we should make protected and private simply behave > as var in PHP 4.x as this would indeed just undermine the entire point > of the E_STRICT warning. > > regards, > Lukas >
I started long ago to prepare code for PHP 5 migration by adding some hint comments /* abstract */ class FooBar { /* public */ var $public; /* protected */ var $protected; /* private */ var $private; /* private */ function __construct(/*PHP5*/$var) {} } When moving to PHP 5 simple search and replace does the job. All places marked with /*PHP5*/& are replaced with empty string - thus unnecessary references in the code are removed. The code base be easily preprocessed and one code base can be used in most cases to be run under 4 and 5. Andrey

Rasmus Lerdorf

21 years ago
Lukas Smith wrote:
> Stanislav Malyshev wrote: > >> I wonder what was the original purpose of PHP5 emitting warning when >> seeing 'var'? What are you basically saying now is "I want PHP4 code >> that wouldn't have messages on my class vars if run in PHP5". But I'm >> sure there was some idea behind these warnings, not? > > > There was a reason. So that people who mark things "var" because there > was no true PPP available will be notified that they are using > deprecated syntax. To quote Andi "It was meant to help people find var's > so that they can be explicit about the access modifiers." > > So to me it seems if I have no private/protected, but only public > properties I would like to be able to preempt a needless warning as I > migrade to PHP5. > > I dont agree however we should make protected and private simply behave > as var in PHP 4.x as this would indeed just undermine the entire point > of the E_STRICT warning.
Right. To me PHP4 OO code with explicit var declarations are public declarations, because that is what var means. I find most code I look at that has something that the developer might want to make private in PHP5 are not explicitly declared with var. Of course, I am not actually seeing this warning right now, so maybe this has gone away? Or what am I missing? error_reporting(E_ALL|E_STRICT); ini_set('display_errors',1); class foo { var $prop; function foo($arg) { $this->_private = $arg; $this->prop = $this->_private * 10; } } $a = new foo(14); echo $a->prop; I am not seeing an E_STRICT from this. -Rasmus

Rasmus Lerdorf

21 years ago
Rasmus Lerdorf wrote:
> Lukas Smith wrote: > >>Stanislav Malyshev wrote: >> >> >>>I wonder what was the original purpose of PHP5 emitting warning when >>>seeing 'var'? What are you basically saying now is "I want PHP4 code >>>that wouldn't have messages on my class vars if run in PHP5". But I'm >>>sure there was some idea behind these warnings, not? >> >> >>There was a reason. So that people who mark things "var" because there >>was no true PPP available will be notified that they are using >>deprecated syntax. To quote Andi "It was meant to help people find var's >>so that they can be explicit about the access modifiers." >> >>So to me it seems if I have no private/protected, but only public >>properties I would like to be able to preempt a needless warning as I >>migrade to PHP5. >> >>I dont agree however we should make protected and private simply behave >>as var in PHP 4.x as this would indeed just undermine the entire point >>of the E_STRICT warning. > > > Right. To me PHP4 OO code with explicit var declarations are public > declarations, because that is what var means. I find most code I look > at that has something that the developer might want to make private in > PHP5 are not explicitly declared with var. > > Of course, I am not actually seeing this warning right now, so maybe > this has gone away? Or what am I missing? > > error_reporting(E_ALL|E_STRICT); > ini_set('display_errors',1); > > class foo { > var $prop; > function foo($arg) { > $this->_private = $arg; > $this->prop = $this->_private * 10; > } > } > $a = new foo(14); > echo $a->prop; > > I am not seeing an E_STRICT from this.
Uh, never mind, I had restarted the Apache. Of course you need this in your php.ini to catch compile-time stuff. -Rasmus

Pierre-Alain Joye

21 years ago
On Wed, 15 Jun 2005 16:36:38 +0200 lsmith@php.net (Lukas Smith) wrote:
> Stanislav Malyshev wrote: > > > LS>>I think its a good idea to have, to make it somewhat > > LS>>possible to prepare for the PHP5 E_STRICT world, while > > LS>>still developing PHP4 compatible code. I could for example > > LS>>see this help increase the PHP5 adoption inside PEAR, > > > > Like, PEAR would drop support for PHP 4.3 or it would have two > > copies of the code - one with public keyword and one without? > > Currently PEAR.php requires PHP 4.2. > We could eventually (as an intermediate step) move this dep to > 4.4, not immediatly. However currently there is a strong trend to > create new versions of packages for the main reason of making > them E_STRICT compatible. However lets not get too far into the > PEAR politics here ;-)
I have no oppinion about public (I do not like forward compatibility in general :)). Abour PEAR minumum dep, we plan to move to 4.3 once 4.4 or 5.1 is out, but not 4.4. My other concern is that there is other issues brought by php5, using public will not solve them. I do not have some in mind right now but sounds like a bad idea to consider a package E_STRICT compliant only by adding public :)
> Anyways I just wanted to give this as an example. I think its > much more useful for independent developers who have more control > over their user setups than PEAR. This allows them to make the > move less painful and therefore will facilitate rather than > prolong the move to PHP5 (which is a good thing).
My oppinion differs here, providing ways to keep php4 running will delay the move. They only have to add public to feel safe under php5. Regards, --Pierre

Sebastian Mendel

21 years ago
Pierre-Alain Joye wrote:
>>> LS>>I think its a good idea to have, to make it somewhat >>> LS>>possible to prepare for the PHP5 E_STRICT world, while >>> LS>>still developing PHP4 compatible code. I could for example >>> LS>>see this help increase the PHP5 adoption inside PEAR, >>> >>> Like, PEAR would drop support for PHP 4.3 or it would have two >>> copies of the code - one with public keyword and one without? >> Currently PEAR.php requires PHP 4.2. >> We could eventually (as an intermediate step) move this dep to >> 4.4, not immediatly. However currently there is a strong trend to >> create new versions of packages for the main reason of making >> them E_STRICT compatible. However lets not get too far into the >> PEAR politics here ;-) > > I have no oppinion about public (I do not like forward > compatibility in general :)). Abour PEAR minumum dep, we plan to > move to 4.3 once 4.4 or 5.1 is out, but not 4.4. > > My other concern is that there is other issues brought by php5, > using public will not solve them. I do not have some in mind right > now but sounds like a bad idea to consider a package E_STRICT > compliant only by adding public :) > >> Anyways I just wanted to give this as an example. I think its >> much more useful for independent developers who have more control >> over their user setups than PEAR. This allows them to make the >> move less painful and therefore will facilitate rather than >> prolong the move to PHP5 (which is a good thing). > > My oppinion differs here, providing ways to keep php4 running will > delay the move. They only have to add public to feel safe under > php5.
i fully agree with Lukas i dont think that this would delay it, IMHO is 'var' the only thing that produces NOTICES in PHP 5 what can not be changed if this app should run in both Versions 4 and 5, others, like '= new' and '=& new' can easily be adopt by just removing the '&' without getting any NOTICE in any VERSION i think 'var' is the most important reason for the current delay in the move to PHP 5! i would even go a step further: -<ST_IN_SCRIPTING>"var" { +<ST_IN_SCRIPTING>("var"|"public"|"private"|"protected") { btw. PHP 4.4 should raise also a NOTICE when someone trys to overwrite $this, as this is not possible in PHP 5
-- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

Stanislav Malyshev

21 years ago
SM>>IMHO is 'var' the only thing that produces NOTICES in PHP 5 what can SM>>not be changed if this app should run in both Versions 4 and 5, SM>>others, like '= new' and '=& new' can easily be adopt by just removing SM>>the '&' without getting any NOTICE in any VERSION Here's something I am missing - if you say notices are so much rpoblem, why not remove them? SM>>i think 'var' is the most important reason for the current delay in the SM>>move to PHP 5! Eh? Why is that? Is it so hard to write one one-line script that would replace ALL vars to publics? SM>>i would even go a step further: SM>> SM>>-<ST_IN_SCRIPTING>"var" { SM>>+<ST_IN_SCRIPTING>("var"|"public"|"private"|"protected") { Ouch. So you could write code that would run on PHP4 perfectly well and break on PHP5?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Sebastian Mendel

21 years ago
Stanislav Malyshev wrote:
> SM>>IMHO is 'var' the only thing that produces NOTICES in PHP 5 what can > SM>>not be changed if this app should run in both Versions 4 and 5, > SM>>others, like '= new' and '=& new' can easily be adopt by just removing > SM>>the '&' without getting any NOTICE in any VERSION > > Here's something I am missing - if you say notices are so much rpoblem, > why not remove them?
oh, PHP introduced NOTICEs so that i remove them? great ...
> SM>>i think 'var' is the most important reason for the current delay in the > SM>>move to PHP 5! > > Eh? Why is that? Is it so hard to write one one-line script that would > replace ALL vars to publics?
no but this so changed app could not run on both versions at the current state i can run one Server with both versions, accessing with different virtual hosts the same script ones interprated by PHP 5 and on the other vhost with PHP 4, but with Notices enabled i get overhelmed by 'var is deprecated'
> SM>>i would even go a step further: > SM>> > SM>>-<ST_IN_SCRIPTING>"var" { > SM>>+<ST_IN_SCRIPTING>("var"|"public"|"private"|"protected") { > > Ouch. So you could write code that would run on PHP4 perfectly well and > break on PHP5?
this can be done already, just to mention overwriting $this, or changing a copy of an object in PHP 4 changes the original object in PHP 5 also, this all three are 'silent' changes - that reports no errors but can break the app but this are all errors that can be fixed without getting notices in both versions but work in both versions
-- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

Stanislav Malyshev

21 years ago
SM>>> Here's something I am missing - if you say notices are so much rpoblem, SM>>> why not remove them? SM>> SM>>oh, PHP introduced NOTICEs so that i remove them? great ... But that's _exactly_ what is proposed - to add a keyword to PHP to only to remove notices that PHP produces.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Sebastian Mendel

21 years ago
Stanislav Malyshev wrote:
> SM>>> Here's something I am missing - if you say notices are so much rpoblem, > SM>>> why not remove them? > SM>> > SM>>oh, PHP introduced NOTICEs so that i remove them? great ... > > But that's _exactly_ what is proposed - to add a keyword to PHP to > only to remove notices that PHP produces.
oh, so is it wrong to fix something that produces a NOTICE? and to fix this with the help of forward-compatibility? and this keyword is added in _PHP 4_, there is no NOTICE
-- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

Rasmus Lerdorf

21 years ago
Stanislav Malyshev wrote:
> LS>> > LS>>A while ago someone on IRC suggested that it might be a good idea to add > LS>>"public" to PHP 4.x for forward compatibility. I brought it up again on IRC > LS>>yesterday and several prominent members of the php core community said it > LS>>would be a good idea to add to the 4.4 branch. > > Why it would be a good idea? You couldn't run this code on 4.x{x<4} > anymore. And you still don't have php5 capabilities. So you get PHP > code which has all PHP 4 restrictions plus is not portable to arbitrary > PHP 4 version and requires only php 4.4 to run. How is it good? > > LS>>I think its a good idea to have, to make it somewhat possible to prepare for > LS>>the PHP5 E_STRICT world, while still developing PHP4 compatible code. I > LS>>could for example see this help increase the PHP5 adoption inside PEAR, > > Like, PEAR would drop support for PHP 4.3 or it would have two copies of > the code - one with public keyword and one without?
It's not just about Pear. There are plenty of large codebases out there that need to migrate slowly to PHP5. Since public and var have exactly the same meaning in the two versions, I don't see why making public a synonym for var in PHP 4.4 is in any way detrimental. -Rasmus

Andi Gutmans

21 years ago
Personally, I don't think there's a significant benefit to adding support for public. There are so many differences and new features that the gain of just being able to change "var" to "public" would be marginal at best. That said, I don't mind supporting if people think it will help. It's a tiny patch and doesn't break any serious API compatibility except for the downside of not being able to run PHP 4.4 code on PHP 4.3 (if it uses public), which probably defeats the purpose of supporting both PHP 4 and PHP 5. Again though, we can do it... It's no biggy. Andi

Rasmus Lerdorf

21 years ago
Andi Gutmans wrote:
> Personally, I don't think there's a significant benefit to adding > support for public. There are so many differences and new features that > the gain of just being able to change "var" to "public" would be > marginal at best. > > That said, I don't mind supporting if people think it will help. It's a > tiny patch and doesn't break any serious API compatibility except for > the downside of not being able to run PHP 4.4 code on PHP 4.3 (if it > uses public), which probably defeats the purpose of supporting both PHP > 4 and PHP 5. > > Again though, we can do it... It's no biggy.
What was the reasoning again for not having var be a synonym for public in PHP5? It is a bit annoying that a simple PHP4 class using var throws a notice in PHP5 when there is technically nothing wrong with it. -Rasmus

Mike Bretz

21 years ago
Rasmus Lerdorf wrote:
>What was the reasoning again for not having var be a synonym for public >in PHP5? It is a bit annoying that a simple PHP4 class using var throws >a notice in PHP5 when there is technically nothing wrong with it. > >-Rasmus > > >
I personally don't support "forward compatibility" as well. Especially when talking about a php 4.x tree, which has to be "downward" compatible as well. Introducing a new synonym allowing to develop "upward" compatible php code at least breaks this rule. On the other hand I don't believe that this synonym would help in any way to produce good perfoming "pre-php5" code. Why not make PHP5 not complaining about those php4 "var" definitions at all? Maybe a new error level for "deprecated" keywords (and function calls) would be helpful? mike
-- mike peter bretz metropolis ag / entwicklung email: m.bretz@metropolis-ag.de heinestraße 72 phone: +49-7121-348-120 d-72762 reutlingen fax: +49-7121-348-111 http://www.metropolis-ag.de/ metropolis ag. creating social internetworks.

Sebastian Mendel

21 years ago
Mike Bretz wrote:
> Rasmus Lerdorf wrote: > >> What was the reasoning again for not having var be a synonym for public >> in PHP5? It is a bit annoying that a simple PHP4 class using var throws >> a notice in PHP5 when there is technically nothing wrong with it. >> >> -Rasmus > > I personally don't support "forward compatibility" as well. Especially > when talking about a php 4.x tree, which has to be "downward" compatible > as well. Introducing a new synonym allowing to develop "upward" > compatible php code at least breaks this rule. On the other hand I don't > believe that this synonym would help in any way to produce good > perfoming "pre-php5" code. > > Why not make PHP5 not complaining about those php4 "var" definitions at > all? > Maybe a new error level for "deprecated" keywords (and function calls) > would be helpful?
and is it a problem to implement such a new error level also with PHP 4.4. for example reporting overwriting $this is not allowed in PHP 5 ? and, when we are at this, what about 'clone' as a dummy-keyword in PHP 4.4 ?
-- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

Lukas Smith

21 years ago
Sebastian Mendel wrote:
> and is it a problem to implement such a new error level also with PHP > 4.4. for example reporting overwriting $this is not allowed in PHP 5 ? > > and, when we are at this, what about 'clone' as a dummy-keyword in PHP 4.4 ?
err no .. because that would break existing php 4 code in 4.4 regards, Lukas

Sebastian Mendel

21 years ago
Lukas Smith wrote:
> Sebastian Mendel wrote: > >> and is it a problem to implement such a new error level also with PHP >> 4.4. for example reporting overwriting $this is not allowed in PHP 5 ? >> >> and, when we are at this, what about 'clone' as a dummy-keyword in PHP >> 4.4 ? > > err no .. because that would break existing php 4 code in 4.4
what exactly? the new error-level? the message with this new error-level? or the dummy-keyword? sorry but i didnt see this.
-- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

Johannes Schlueter

21 years ago
Hi Sebastian, On Thursday 16 June 2005 11:16, Sebastian Mendel wrote:
> > err no .. because that would break existing php 4 code in 4.4 > > what exactly? the new error-level? the message with this new > error-level? or the dummy-keyword? > > sorry but i didnt see this.
That an error, which isn't expected by an error handler, is being thrown or that somebody[tm] activates this error level and the messages appear in the output. This kind of "forward compatibility" doesn't make any sense to me. johannes

Robert Cummings

21 years ago
On Wed, 2005-06-15 at 13:21, Rasmus Lerdorf wrote:
> Andi Gutmans wrote: > > Personally, I don't think there's a significant benefit to adding > > support for public. There are so many differences and new features that > > the gain of just being able to change "var" to "public" would be > > marginal at best. > > > > That said, I don't mind supporting if people think it will help. It's a > > tiny patch and doesn't break any serious API compatibility except for > > the downside of not being able to run PHP 4.4 code on PHP 4.3 (if it > > uses public), which probably defeats the purpose of supporting both PHP > > 4 and PHP 5. > > > > Again though, we can do it... It's no biggy. > > What was the reasoning again for not having var be a synonym for public > in PHP5? It is a bit annoying that a simple PHP4 class using var throws > a notice in PHP5 when there is technically nothing wrong with it.
*hah* I was just about to ask that. Seems silly that PHP5 didn't just treat var as a public declaration. I put a dirty hack in my framework that filters warnings in the error handler related to "var" warnings. I see absolutely no reason why I should break PHP4 compatibility and maintain 2 versions of the framework because "var" generates a warning. And I refuse to develop with reduced error level (I think reducing error level is a cop out that leads to poor code). Cheers, Rob.
-- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'

Andi Gutmans

21 years ago
No strong reason. It was meant to help people find var's so that they can be explicit about the access modifiers. This is why it was put in E_STRICT. It's meant to be more helpful and informational messages, and you shouldn't run your website in E_STRICT. Maybe the difference here are the expectations of E_STRICT. I always saw it as a strict standards flag, which is only for the people who are perfectionists. I think it can be useful to some people but I don't mind removing the message. Andi At 10:21 AM 6/15/2005 -0700, Rasmus Lerdorf wrote:

Stephan Schmidt

21 years ago
Hi, Lukas Smith wrote:
> I think its a good idea to have, to make it somewhat possible to prepare > for the PHP5 E_STRICT world, while still developing PHP4 compatible > code. I could for example see this help increase the PHP5 adoption > inside PEAR, since this would allow us to make some packages E_STRICT > compatible without throwing out PHP4 compatibility (inside PEAR we > consider increased major PHP versions to be a BC break, but not minor > versions).
Will this still work in PHP 4.4 as it did in 4.3 if you apply the patch? function public($foo) { var_dump($foo); } public(42); I guess, this will more likely produce an error message like this: Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in public.php on line 2 So I'm strongly against this change. If you want to run PHP4 code in PHP5, disable E_STRICT. Just my 2 cts, Stephan

Sebastian Mendel

21 years ago
Stephan Schmidt wrote:
> Hi, > > Lukas Smith wrote: >> I think its a good idea to have, to make it somewhat possible to >> prepare for the PHP5 E_STRICT world, while still developing PHP4 >> compatible code. I could for example see this help increase the PHP5 >> adoption inside PEAR, since this would allow us to make some packages >> E_STRICT compatible without throwing out PHP4 compatibility (inside >> PEAR we consider increased major PHP versions to be a BC break, but >> not minor versions). > > Will this still work in PHP 4.4 as it did in 4.3 if you apply the patch? > > function public($foo) { > var_dump($foo); > } > public(42); > > I guess, this will more likely produce an error message like this: > > Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in > public.php on line 2 > > So I'm strongly against this change. If you want to run PHP4 code in > PHP5, disable E_STRICT.
id dont know, but isnt there a difference between where the keywords are placed? and if it is so, then this would also be a candidate for "NOTICE: 'public' is a keyword in PHP 5" in php 4.4
-- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

Johannes Schlueter

21 years ago
On Thursday 16 June 2005 11:27, Sebastian Mendel wrote:
> > I guess, this will more likely produce an error message like this: > > > > Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in > > public.php on line 2
right
> > So I'm strongly against this change. If you want to run PHP4 code in > > PHP5, disable E_STRICT.
+1
> id dont know, but isnt there a difference between where the keywords are > placed?
No, it's a parser keyword and a keyword can't be used as a function name.
> and if it is so, then this would also be a candidate for > > "NOTICE: 'public' is a keyword in PHP 5" in php 4.4
No. No "errors" for "forward compatibility". johannes

Nelson Menezes

21 years ago
I completely agree. This (or any other "public-in-4.4" solution) would only create an extra branch to maintain for both developers and users; no one can expect all of the PHP 4.x base to go 4.4, and code with "public" that "supports php 4 and 5" would actually break in 4.<4 and still would be: - unable to use PHP 5 - subject to the other PHP 4/5 issues Besides, the point of E_STRICT seems to be to _enforce_ best practices -- and if you care about this matter, considering all members as "public" is probably defying the concept anyway. On 6/16/05, Johannes Schlueter <johannes@php.net> wrote:
> On Thursday 16 June 2005 11:27, Sebastian Mendel wrote: > > > I guess, this will more likely produce an error message like this: > > > > > > Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in > > > public.php on line 2 > > right > > > > So I'm strongly against this change. If you want to run PHP4 code in > > > PHP5, disable E_STRICT. > > +1 > > > id dont know, but isnt there a difference between where the keywords are > > placed? > > No, it's a parser keyword and a keyword can't be used as a function name. > > > and if it is so, then this would also be a candidate for > > > > "NOTICE: 'public' is a keyword in PHP 5" in php 4.4 > > No. No "errors" for "forward compatibility". > > johannes > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Nelson Menezes flying.mushroom@gmail.com

Sebastian Mendel

21 years ago
Nelson Menezes wrote:
> On 6/16/05, Johannes Schlueter <johannes@php.net> wrote: >> On Thursday 16 June 2005 11:27, Sebastian Mendel wrote: >>>> I guess, this will more likely produce an error message like this: >>>> >>>> Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in >>>> public.php on line 2 >> >> right >> >>>> So I'm strongly against this change. If you want to run PHP4 code in >>>> PHP5, disable E_STRICT. >> >> +1 >> >>> id dont know, but isnt there a difference between where the keywords are >>> placed? >> >> No, it's a parser keyword and a keyword can't be used as a function name. >> >>> and if it is so, then this would also be a candidate for >>> >>> "NOTICE: 'public' is a keyword in PHP 5" in php 4.4 >> >> No. No "errors" for "forward compatibility". > > I completely agree. This (or any other "public-in-4.4" solution) would > only create an extra branch to maintain for both developers and users; > no one can expect all of the PHP 4.x base to go 4.4, and code with > "public" that "supports php 4 and 5" would actually break in 4.<4 and > still would be: > > - unable to use PHP 5 > - subject to the other PHP 4/5 issues
of course, id dont want any changes that break compatibility!
> Besides, the point of E_STRICT seems to be to _enforce_ best practices > -- and if you care about this matter, considering all members as > "public" is probably defying the concept anyway.
but defining all as public doesnt produces any NOTICEs, neither now nor with the feature we are talking about.
-- Sebastian Mendel www.sebastianmendel.de www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

Nelson Menezes

21 years ago
On 6/17/05, Sebastian Mendel <lists@sebastianmendel.de> wrote:
> > Besides, the point of E_STRICT seems to be to _enforce_ best practices > > -- and if you care about this matter, considering all members as > > "public" is probably defying the concept anyway. > > but defining all as public doesnt produces any NOTICEs, neither now nor > with the feature we are talking about.
True, but that's not the point. E_STRICT complaints about "var" are a way of saying "erm, you actually didn't put much thought into building this class; you should think about the level of visibility of its members". If you don't want those reminders, forget about E_STRICT. If you leave E_STRICT enabled but try to bypass it (by declaring everything as public for BC) then you didn't understand what E_STRICT is for...
-- Nelson Menezes flying.mushroom@gmail.com

Derick Rethans

21 years ago
Hello, after reading this very long thread, and problems with having the public keyword I decided not to allow any kind of forward compability to be introduced into PHP 4.4. Discussion is over. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Rasmus Lerdorf

21 years ago
Derick Rethans wrote:
> Hello, > > after reading this very long thread, and problems with having the public > keyword I decided not to allow any kind of forward compability to be > introduced into PHP 4.4. Discussion is over.
Yeah, I think the change really needs to be in PHP5 instead. Right now the E_STRICT warnings in PHP5 on this stuff are not very useful. They are just strict enough to be annoying by warning about "var" but not strict enough to be useful because there is no warning on undeclared properties. -Rasmus

Zeev Suraski

21 years ago
At 18:30 16/06/2005, Rasmus Lerdorf wrote:
>Derick Rethans wrote: > > Hello, > > > > after reading this very long thread, and problems with having the public > > keyword I decided not to allow any kind of forward compability to be > > introduced into PHP 4.4. Discussion is over. > >Yeah, I think the change really needs to be in PHP5 instead. Right now >the E_STRICT warnings in PHP5 on this stuff are not very useful. They >are just strict enough to be annoying by warning about "var" but not >strict enough to be useful because there is no warning on undeclared >properties.
I agree with half of what you're saying - I think we should also emit E_STRICT in case of creation of undeclared properties. We already have it in pretty much but it's commented out (probably since there was no E_STRICT when it was introduced, and an E_NOTICE was too aggressive). If there are no objections, I'll uncomment it and change it to E_STRICT. I think the E_STRICT warnings on var should stay. Zeev

Derick Rethans

21 years ago
On Thu, 16 Jun 2005, Zeev Suraski wrote:
> At 18:30 16/06/2005, Rasmus Lerdorf wrote: > >Derick Rethans wrote: > > > Hello, > > > > > > after reading this very long thread, and problems with having the public > > > keyword I decided not to allow any kind of forward compability to be > > > introduced into PHP 4.4. Discussion is over. > > > >Yeah, I think the change really needs to be in PHP5 instead. Right now > >the E_STRICT warnings in PHP5 on this stuff are not very useful. They > >are just strict enough to be annoying by warning about "var" but not > >strict enough to be useful because there is no warning on undeclared > >properties. > > I agree with half of what you're saying - I think we should also emit E_STRICT > in case of creation of undeclared properties. We already have it in pretty > much but it's commented out (probably since there was no E_STRICT when it was > introduced, and an E_NOTICE was too aggressive). If there are no objections, > I'll uncomment it and change it to E_STRICT. > > I think the E_STRICT warnings on var should stay.
Yeah, I agree - because it easily shows which classes you didnt port yet. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org