Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34962
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Mon, 28 Jan 2008 15:12:37 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1109819085.20080128151237@marcus-boerger.de>
To: "Robin Fernandes" <rewbs.soal@gmail.com>
CC: internals@lists.php.net, robin@soal.org
In-Reply-To: <5a8807d10801280520u7f8c7a9o8d2ab2efaa9c7644@mail.gmail.com>
References: <5a8807d10801280520u7f8c7a9o8d2ab2efaa9c7644@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Protected static props redeclared as public share value across classes
From: helly@php.net (Marcus Boerger)

Hello Robin,

  expected behavior. The static property is inherited to the sub class. As
that subclass repeats the declaration with a different visibility you simply
change the visibility. If the base class had the property defined as private
then the property is private to that specific class and not directly
accessible by derived classes that is it's name gets prefixed with the class
name. So in:
class A { private static $p; } class B extends A { private static $p; }
we have two different properties:
1) A::p
2) B::p
while in
class A { protected static $p; } class B extends A { public static $p; }
we get just p in A, which then gets into B, so that the public line in p
simply changes the visibility as described above.

marcus

Monday, January 28, 2008, 2:20:56 PM, you wrote:

> Hi all,

> If a protected static property is overridden by a public static
> property, both properties share the same value:

> <?php
> class A {
>       protected static $a;
>       public static function test() {
>               A::$a = 'A::$a';
>               echo A::$a . "\n";  // Prints 'A::$a'
>               echo B::$a . "\n";  // Also prints 'A::$a', because
> A::$a and B::$a share values.
>       }
> }

> class B extends A {
>       public static $a = 'B::$a';
> }

> A::test();
?>>

> This behaviour feels strange to me, because:

> 1. It only applies to that specific combination of visibility
> modifiers. If you change A::$a to public OR B::$a to protected, then
> A::$a and B::$a are treated as two separate entities. See
> pastebin.com/fca2cd5b and pastebin.com/f4f94b32d .

> 2. It is inconsistent with the behaviour of static methods. See:
> pastebin.com/f27f009c4 .

> 3. It differs from the behaviours of C#, Java and C++ (whereas, in
> most other respects, PHP and these languages share a lot of common
> ground regarding the concepts of visibility & static-ness). See:
> http://pastebin.ca/871576, http://pastebin.ca/871975 and
> http://pastebin.ca/871583.

> The code for this behaviour was added to zend_compile.c in rev 1.474
> (back in sept 2003 :). If I change it to ensure that protected A::$a
> and public B::$a are treated as separate entities (quick patch against
> 5.2 snap here: pastebin.com/f7f175924 ), the only tests that fail are
> those specifically designed to check for this behaviour:
> Zend/tests/errmsg_024.phpt and
> ext/reflection/tests/static_properties_002.phpt.


> Is this a bug? If not, could you help me understand the decision to go
> with this inheritance rule?

> Many thanks!
> Robin




Best regards,
 Marcus