On 11/29/10 11:51 AM, Jonathan Bond-Caron wrote:
Right, it looks the same but the subtle difference is 'property Hours'
wouldn't be registered as a class. It's just container code for get(), set()
methods that would get 'compiled' into opcodes in the class TimePeriod (the
property exists vs. searching for it in runtime). So you can think of it as
a special 'trait' that only applies to properties.
The idea behind this syntax is you can move the 'property' definition out of
the class so that you can test and re-use it somewhere else (like traits).
That might not be problem if you can define properties in traits (needs to
be explained in the RFC):
I think I'd prefer to use Traits for externally-defined properties
rather than defining a new top-level construct. It's fewer moving parts
and we don't need to figure out how autoloading would be affected.
(Autoload would work the same way it does now for traits... whatever
that is.)
That would then imply we do need to be able to declare the existence of
a property and whether it has get, set, or both independently of the
definition, just like methods, so that we can have a proper
interface/trait split for properties just as for methods.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
