Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63875
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
To: internals@lists.php.net
Cc: Nikita Popov <nikita.ppv@gmail.com>, Clint Priest <cpriest@zerocue.com>
Date: Wed, 14 Nov 2012 17:24:51 +0100
Message-ID: <58826104.Pqfe10HgIT@rofl>
User-Agent: KMail/4.9.3 (Linux/3.6.6-k10-bof; KDE/4.9.3; x86_64; ; )
In-Reply-To: <CAF+90c_jVmHk_ZXc1GXNwwiZ3Zy8oubmW8gudbmi7qppH68p2A@mail.gmail.com>
References: <508A67E6.2000405@zerocue.com> <50A39C58.6030501@zerocue.com> <CAF+90c_jVmHk_ZXc1GXNwwiZ3Zy8oubmW8gudbmi7qppH68p2A@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)

On Wednesday 14 November 2012 16:35:31 Nikita Popov wrote:
> On Wed, Nov 14, 2012 at 2:27 PM, Clint Priest <cpriest@zerocue.com> wrote:
> > Been AWOL for a while and getting back to this, doesn't seem like any
> > resolution has occurred, just the conversation has died down.
> 
> I got the feeling that in the last few mails we actually made some progress
> and some people agreed with me that __magic accessor methods and a
> dedicated syntax for them are not combinable semantically. Maybe I got that
> wrong :/

I thought I'd made a proposal that would solve that problem, but maybe it was 
overlooked, or more likely too ugly to be recognized as such.

Requires a single new feature / syntax, that at least I find missing right 
now:

class ... {
  no methodname();
   // or
  no $property;
}

removing the specified thing from the class, with the possibility to then 
redefine it. Silently ignore this when the thing doesn't exist.

The mechanism for that could then be used to solve your semantic puzzle, using 
these rules:

- any ordinary property declaration for $foo internally also does
	no __prop_get_foo();
	no __prop_set_foo();
	no __prop_isset_foo();
	no __prop_unset_foo();
- any declaration of these four new magic methods internally also does
       no $foo;

In other words:

whenever a class implements one of the accessor magic methods, an inherited 
property is ignored, as if it wasn't present in the base class(es) in the 
first place.

And whenever a class declares a property in the ordinary way, any inherited 
magic property accessor methods are ignored, as if they were not present in 
the base class(es) in the first place.

Maybe a "final" in the respective base class, would make this attempt an 
ERROR.

What do you think? Should I try to write up an RFC for the "no" feature?

best regards
  Patrick