On Tue, Oct 30, 2012 at 10:52 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> Hi!
>
>> 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.
>
> I see your point now, thanks, but I don't think I agree.
>
>>
>> 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.
>
> I'm not sure why you are expecting this, and also this is probably an
> LSP violation, since such override would change semantics of the value
> that A clients expect. It may be possible to implement, technically, but
> I'm not sure it's the right thing to do.
Why would it be not expected and/or a violation of LSP? Accessors
impose stricly more restrictions than properties. This code is fine.
Just like it is fine in theory to have interface A { public $foo {
get(); set($v); } } class B implements A { public $foo; }
>
>> 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...).
>
> Magic methods are not properties, they are implementation of properties.
> But your properties aren't either - see discussion about interfaces,
> etc. They simulate regular properties but they aren't regular
> properties. E.g., what would happen if you serialize an object with
> simulated property?
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
