Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63730
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
To: internals@lists.php.net
Cc: Nikita Popov <nikita.ppv@gmail.com>, Stas Malyshev <smalyshev@sugarcrm.com>, Clint Priest <cpriest@zerocue.com>
Date: Wed, 31 Oct 2012 13:29:15 +0100
Message-ID: <7818029.ra9XhW6Vax@rofl>
User-Agent: KMail/4.9.2 (Linux/3.6.3-k10-bof; KDE/4.9.2; x86_64; ; )
In-Reply-To: <CAF+90c8MLs21T-HsDA8KH7js5BDz4fQceruTWncUzcw61Km6jg@mail.gmail.com>
References: <508A67E6.2000405@zerocue.com> <508EFB76.4080604@sugarcrm.com> <CAF+90c8MLs21T-HsDA8KH7js5BDz4fQceruTWncUzcw61Km6jg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
From: php@bof.de (Patrick Schaaf)

Nikita, your examples convinced me that a strict "accessor methods as 
specialized __get/__set semantics" approach is undesirable.

To recapitulate your two examples:

Example 1:

class A {
  public $foo;
}
class B extends A {
  public $foo { get() { ...} }
}

Example 2:

class A {
  public $foo { get() { ...} }
}
class B extends A {
  public $foo;
}

One would expect that in both cases, instances of 'class B' would have a $foo 
acting as declared in class B, shadowing the declaration from class A.

I think that the issue might be solved by an additional, not-yet-discussed and 
very general extension, which is something I missed being able to do from time 
to time: the possibility to declare a method (or property) in some class to be 
explicitly NOT inherited. Syntactically, something like

class C {
  public $bar;
  public function twiddle();
}
class D extends C {
  no public $bar;
  no public function twiddle();
 # might be followed by a different twiddle(), or $bar, implementation
}

The use case I have in mind, coming from the method side, is a subclass that 
wants to use __call() for delegation AND needs to delegate to one or more 
methods that are ordinarily plainly implemented in the base class.

What this feature would bring to the current discussion, is this possible 
solution to your dilemma:

1) when a class declares a plain property "public $foo", automatically apply
"no function __getfoo(); no function setfoo();" (leaving out isset/unset for 
clarity)
2) conversely, when a class declares "public $foo { get() {...}}", or even 
just declares one of the magic methods directly like "public function 
__getfoo() {}" - automatically prepend / pretend a "no public $foo;" 
cancelling a superclass property.

best regards
  Patrick