Hi!
However, assignment overloading does not seem viable to me. Also, I'm not sure how this is possible technically: $obj = {expression} is supposed to replace $obj with the result of the expression, not call methods on $obj.The engine already calls methods on $obj when that happens. That's the set handler. It just happens that user classes have a null set handler, which is why it works the way it does. Internal classes have full ability to work this way...
This is internal implementation detail. Having it in the guts of the engine is one thing, exposing it to the user is quite another. The engine can also access arbitrary memory addresses and write arbitrary data there, but we don't propose to let the user do the same in PHP.
Pedantic note: It already means different things. We have notices if it's not set, and it behaves differently if references are involved. So already we have a few different effects on what happens depending on where and how $obj was defined. So I fail to see how this is *that* much of a shift.
Again, you seem to miss important differences here. Providing notices when something is wrong in the expression is one thing, changing semantics of assignment is quite another. Saying "because we have notices it's also OK to have completely different semantics" makes very little sense to me.
really what it can enable is really powerful. Additionally, the code is already there, and there are already classes using that code (SimpleXML for one). So it's not like it's introducing new functionality, it's just exposing the existing functionality to be leveraged by PHP land code...
SimpleXML does not change semantics of assignment. It uses some engine trickery to achieve what it does but the semantics exposed to the user is simple and intuitive. You propose to create ability to introduce semantics which in its intended usage will be both counterintuitive and disagreeing with how the engine works now.
-- 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
