Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36612
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.82.225 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=LITurZMJtREVDAYNXeoNg3fJ85N68ZBIkpPFvt936Q+WOVzH+V3F3pkTVhdBAKVcrqPQWkWzVAFcCxvEHa/Khvn1nanEifawiJhwDlscfxwQMgVYdqJGfsuTkrdqQeOU3Bn/4HBD+Yz2LhR65PlgIY9BMIFR4maKTcDkBUD4SmE=
Message-ID: <5a8807d10803270359x5e7cb315m64e5f22e248129cd@mail.gmail.com>
Date: Thu, 27 Mar 2008 10:59:51 +0000
Reply-To: robin@soal.org
To: "Marcus Boerger" <helly@php.net>, internals <internals@lists.php.net>
Cc: "Alexey Zakhlestin" <indeyets@gmail.com>, RQuadling@googlemail.com, 
	"Felipe Pena" <felipensp@gmail.com>, 
	"Lars Strojny" <lars@strojny.net>
In-Reply-To: <56335354.20080326181859@marcus-boerger.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <5a8807d10802050343r43742844we89366ec47b57f4b@mail.gmail.com>
	 <46ccd1ab0803241816k413c7605p2c3fb9139afd8536@mail.gmail.com>
	 <5a8807d10803250404o6fd33662wbbf3ff14d296cb2a@mail.gmail.com>
	 <1206444907.11368.4.camel@localhost> <1206445347.5400.1.camel@felipe>
	 <10845a340803260945u7a49d991uac5d39be13cca988@mail.gmail.com>
	 <10845a340803260956g6166feaboc04e55c88a9a1a8c@mail.gmail.com>
	 <cd5680a20803261005x8c43da2o4eee0379db3e46b1@mail.gmail.com>
	 <56335354.20080326181859@marcus-boerger.de>
Subject: Re: [PHP-DEV] Inconsistencies when accessing protected members
From: rewbs.soal@gmail.com ("Robin Fernandes")

Hi all, thanks for thinking about this.

On 26/03/2008, Marcus Boerger <helly@php.net> wrote:

> On 26/03/2008, Alexey Zakhlestin <indeyets@gmail.com> wrote:
>
>  > use case for "protected" is similiar, but relates to cases when you
>  > have hierarchy of classes, which still have some common functionality,
>  > which might be usable for multi-instance operations
>
> Thanks. This is the exact way we see this. Anything that violates this rule
>  is a bug.

Ok, good. So to get back to the original question
(http://turl.ca/kfanjo), in the following case, should B1::f() be
visible from B2 in the code example below? Note that:

  - B1 and B2 both extend A. B2 is neither an ancestor nor a
descendant of B1, but I suppose they could be considered to be part of
the same class hierarchy because they are siblings.
  - f() is declared as protected in A and B1, but not declared at all in B2.
  - The docs state: "Protected limits access to inherited and parent
classes (and to the class that defines the item)" -
http://php.net/manual/en/language.oop5.visibility.php .

Currently, B1::f() is visible from B2.

--> If this is a bug, Felipe's patch
(http://ecl.mediain.com.br/diff/protected.diff) fixes the issue. Let's
commit it! :)

--> If this is not a bug then the docs need to be clarified.
Furthermore, callbacks, is_callable(), lookups to the clone & destruct
magic methods and possibly property access should all be changed,
because they currently do not adhere to this rule (as illustrated in
the code snippets in http://turl.ca/kfanjo ).

The code:

<?php
class A {
	static protected function f() {return 'In A::f';}
}
class B1 extends A {
	static protected function f() {return 'In B1::f';}
}
class B2 extends A {
	static public function test() {echo B1::f();}  // Currently, this works.
}
B2::test();
?>

Regards,
Robin.