# forward compatibility "public" in 4.4

- Thread: https://externals.io/message/16685
- Original archive: https://news-web.php.net/php.internals/16685
- Started by Lukas Smith on 2005-06-15T14:12:24+00:00
- Messages: 25
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #16685 — Lukas Smith — 2005-06-15T14:12:24+00:00

URL: https://externals.io/message/16685#16685

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

---

## #16686 — Ilia Alshanetsky — 2005-06-15T14:15:16+00:00

URL: https://externals.io/message/16685#16686 · In reply to: #16685

+1.

The patch is actually a one liner :)

-<ST_IN_SCRIPTING>"var" {
+<ST_IN_SCRIPTING>("var"|"public") {


Ilia

---

## #16690 — Stanislav Malyshev — 2005-06-15T14:30:28+00:00

URL: https://externals.io/message/16685#16690 · In reply to: #16685

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

---

## #16687 — Lukas Smith — 2005-06-15T14:36:38+00:00

URL: https://externals.io/message/16685#16687 · In reply to: #16690

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

---

## #16688 — Stanislav Malyshev — 2005-06-15T15:01:39+00:00

URL: https://externals.io/message/16685#16688 · In reply to: #16687

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

---

## #16689 — Gareth Ardron — 2005-06-15T15:09:24+00:00

URL: https://externals.io/message/16685#16689 · In reply to: #16688

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.

---

## #16691 — Pierre-Alain Joye — 2005-06-15T15:14:33+00:00

URL: https://externals.io/message/16685#16691 · In reply to: #16687

On Wed, 15 Jun 2005 16:36:38 +0200
lsmith@php.net (Lukas Smith) wrote:

> Stanislav Malyshev wrote:
> 
> > […]
> 
> 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

---

## #16692 — Sebastian Mendel — 2005-06-15T15:36:05+00:00

URL: https://externals.io/message/16685#16692 · In reply to: #16691

Pierre-Alain Joye wrote:

> > […]
> 
> 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 :)
> 
> > […]
> 
> 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

---

## #16693 — Stanislav Malyshev — 2005-06-15T15:37:52+00:00

URL: https://externals.io/message/16685#16693 · In reply to: #16692

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

---

## #16694 — Sebastian Mendel — 2005-06-15T16:09:00+00:00

URL: https://externals.io/message/16685#16694 · In reply to: #16693

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

---

## #16695 — Stanislav Malyshev — 2005-06-15T16:11:18+00:00

URL: https://externals.io/message/16685#16695 · In reply to: #16694

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

---

## #16696 — Rasmus Lerdorf — 2005-06-15T16:18:34+00:00

URL: https://externals.io/message/16685#16696 · In reply to: #16690

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

---

## #16708 — Lukas Smith — 2005-06-15T21:48:39+00:00

URL: https://externals.io/message/16685#16708 · In reply to: #16688

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

---

## #16710 — Andrey Hristov — 2005-06-15T22:12:08+00:00

URL: https://externals.io/message/16685#16710 · In reply to: #16708

Lukas Smith wrote:
> Stanislav Malyshev wrote:
> 
> > […]
> 
> 
> 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

---

## #16711 — Rasmus Lerdorf — 2005-06-15T22:19:21+00:00

URL: https://externals.io/message/16685#16711 · In reply to: #16708

Lukas Smith wrote:
> Stanislav Malyshev wrote:
> 
> > […]
> 
> 
> 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

---

## #16712 — Rasmus Lerdorf — 2005-06-15T22:26:10+00:00

URL: https://externals.io/message/16685#16712 · In reply to: #16711

Rasmus Lerdorf wrote:
> Lukas Smith wrote:
> 
> > […]
> 
> 
> 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

---

## #16716 — Sebastian Mendel — 2005-06-16T07:00:41+00:00

URL: https://externals.io/message/16685#16716 · In reply to: #16695

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

---

## #16719 — Stephan Schmidt — 2005-06-16T08:55:54+00:00

URL: https://externals.io/message/16685#16719 · In reply to: #16685

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

---

## #16723 — Johannes Schlueter — 2005-06-16T09:26:43+00:00

URL: https://externals.io/message/16685#16723 · In reply to: #16721

> > […]

right

> > […]

+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

---

## #16721 — Sebastian Mendel — 2005-06-16T09:27:00+00:00

URL: https://externals.io/message/16685#16721 · In reply to: #16719

Stephan Schmidt wrote:
> Hi,
> 
> Lukas Smith wrote:
> > […]
> 
> 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

---

## #16724 — Nelson Menezes — 2005-06-16T11:52:44+00:00

URL: https://externals.io/message/16685#16724 · In reply to: #16723

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.



> 
> > […]
> 
> right
> 
> > […]
> 
> +1
> 
> > […]
> 
> No, it's a parser keyword and a keyword can't be used as a function name.
> 
> > […]
> 
> No. No "errors" for "forward compatibility".
> 
> johannes
> 
> --
> 
> 
> 
> 


-- 
Nelson Menezes
flying.mushroom@gmail.com

---

## #16726 — Derick Rethans — 2005-06-16T12:01:08+00:00

URL: https://externals.io/message/16685#16726 · In reply to: #16685

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

---

## #16738 — Rasmus Lerdorf — 2005-06-16T15:30:03+00:00

URL: https://externals.io/message/16685#16738 · In reply to: #16726

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

---

## #16772 — Sebastian Mendel — 2005-06-17T06:10:19+00:00

URL: https://externals.io/message/16685#16772 · In reply to: #16724

Nelson Menezes wrote:

> 
> > […]
>
> 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

---

## #16773 — Nelson Menezes — 2005-06-17T08:54:00+00:00

URL: https://externals.io/message/16685#16773 · In reply to: #16772

> > […]
> 
> 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