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