Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63708
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <508EFB76.4080604@sugarcrm.com>
References: <508A67E6.2000405@zerocue.com>
	<508A9AC9.50200@sugarcrm.com>
	<CAF+90c-VmscV0q=RAk7FE6+RLhjY8t9CRGY7QqpjB+3=b2XJTQ@mail.gmail.com>
	<508AF3E7.7020004@sugarcrm.com>
	<CAF+90c-RXwG7r=BW6_pDjRTaO3vJx6fGJhdwXV38GqHfBZNHVw@mail.gmail.com>
	<508B1EA2.8060203@sugarcrm.com>
	<508C249D.1000309@zerocue.com>
	<508C43ED.9000209@sugarcrm.com>
	<508C80C6.9000008@zerocue.com>
	<508CD916.1070509@sugarcrm.com>
	<508D5462.4070503@zerocue.com>
	<CAF+90c9xfOoZ13VN1xibXmUGCVfdGb3ymca=M5T86SSU9pY5zA@mail.gmail.com>
	<508EFB76.4080604@sugarcrm.com>
Date: Mon, 29 Oct 2012 23:17:44 +0100
Message-ID: <CAF+90c8MLs21T-HsDA8KH7js5BDz4fQceruTWncUzcw61Km6jg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Clint Priest <cpriest@zerocue.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor
 Method Visibility / Callability
From: nikita.ppv@gmail.com (Nikita Popov)

On Mon, Oct 29, 2012 at 10:56 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> If I got it right now, what Stas wants is that we introduce __getFoo
>> and __setFoo methods that will be called whenever an undefined ->foo
>> property is accessed and that the "normal" property accessors syntax
>> is made nothing more than a fancy notation for this.
>
> Yes, pretty much, though "undefined" bit is not required I think. Not
> 100% convinced on this, but from user reqs it sounds like they want to
> drop the undefined bit.
>
>> A) Inheritance:
>> ==========
>>
>>     class A {
>>         public $foo;
>>     }
>>
>>     class B extends A {
>>         public $foo { get() { ... } set($value) { ... } }
>>     }
>>
>> => With the accessors syntax there is an expectation that the accessor
>> declaration will override the previous plain property. At least that's
>> what I would expect and that's what the code looks like
>
> That's why I'm not liking the "undefined" bit.
>
>> => With the magic syntax there is the expectation that the $foo
>> property will not be overridden. Rather the magic functions are
>> expected to do nothing, because the property already exists.
>
> Err, I'm not sure why that would be the expectation. __get is for
> undefined properties, since, well, it doesn't have any property name
> attached, so it can't really be for defined properties :) However,
> __getFoo (with whatever variations the bikeshedding committee will end
> up with :) has property name attached to it, so requiring property be
> undefined is not, well, required. Here we need to think which way is
> better, and I currently tend to think accessor priority is better.

Stas, you seem to have missed the point behind my mail. This wasn't
about what the exact details of the implementation will be, the
message was that the semantics of a dedicated accessors syntax and the
semantics of a magic implementation can not match.

E.g. assuming that magic accessors take priority over properties as
you want it this time I can just turn the examples around:

    class A {
        public $foo { get() { ... } set($value) { ... } }
    }

    class B extends A {
        public $foo;
    }

=> Here I would expect that public $foo from class B overrides public
$foo from class A. With __ magic on the other hand:

    class A {
        public function __getFoo() { ... }
        public function __setFoo($value) { ... }
    }

    class B extends A {
        public $foo;
    }

=> Here (according to your new overriding priority) the property in
class B would not override, rather the magic from A stays intact.

Basically any kind of interaction between properties and accessor
properties will be broken and inherently so, simply because magic
methods are not real properties (quite obviously...).

Nikita