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.
> 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
