Stas, > Because the engine doesn't run code when parsing class definitions so > defaults should be constants (otherwise would also create a lot of > trouble for bytecode caching as object are not cacheable).
Just throwing this out there, but that code wouldn't be run on parse. It would be "queued" to run prior to the constructor on instantiation. So then, we should be able to execute that code inside of _object_and_properties_init... Then, all you'd need to do is add a single field to _zend_property_info to indicate it should be a class instantiation. From there, you'd want a flag on zend_class_entry to indicate if it has any dynamic properties. So the work flow would be that in _object_and_properties_init, when it copies the hash table, check the flag on the zce. If true, iterate over the properties to check for instantiation, and if so, do it. This would (in theory) be able to support almost any type of dynamic code in the property declaration, as long as it doesn't reference `$this` (which would still be undefined at that point). So you could do: protected $foo = "bar" . BAZ; protected $fiz = new Biz(new Baz, array(123)); Just a thought... Anthony On Fri, Apr 13, 2012 at 4:06 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > >> Why can't we create a new object and assign it to property like this? > > Because the engine doesn't run code when parsing class definitions so > defaults should be constants (otherwise would also create a lot of > trouble for bytecode caching as object are not cacheable). > > Use ctor for complex initializations. > > -- > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
