forward compatibility "public" in 4.4 View as Markdown

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

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

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

Nelson Menezes 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