Re: [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability

On Tue, Oct 30, 2012 at 10:52 PM, Stas Malyshev <smalyshev@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