On Wed, 29 Feb 2012 08:48:07 +0100, Stas Malyshev <smalys...@sugarcrm.com>
wrote:
Hi!
Hey all,
I've created a draft version of the RFC for implementing __castTo()
and __assign():
https://wiki.php.net/rfc/object_cast_magic
I think having cast method may have merits, though use cases where
objects need to be converted to scalars that aren't string are very
limited, and cases where they need to do so transparently are almost
non-existent.
I can think of a few: bridges to foreign types (e.g. Java objects),
SimpleXML like libraries and bigint objects, for instance. The RFC has
more examples.
I think what outlined in the RFC is a backdoor operator
overloading, through rather complex and unobvious magic. My opinion is
that outside of very limited number of cases (such as implementing
complex numbers or matrix algebra - and how frequently would one need do
that in PHP anyway?) operator overloading is way more trouble than it's
worth and makes code nearly unreadable as you never know what exactly
each operator does. For example, if($object) would have completely
different semantics than before, for some objects but not other, and
without any obvious clue to the user what it actually does - and all
that to save couple of keystrokes on if($object->valid())?
This is nothing like operator overloading -- it's much more limited in
scope. Let's say you have two objects $a and $b. Then what this would
allow would be $a + $b yielding a scalar like 5. Operator overloading
would have that expression having the same effect as $a->operator+($b),
which is much powerful. This effectively limits the scope of the feature
to objects with make sense to treat as scalars and then effectively
converts them to scalars in those circumstances.
Still, if there's a valid use case found, cast magic method and
"unboxing" method may have merit. [...]
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. Doing otherwise would be huge change in the semantics,
a complete no go. [...]
Just like $a->foo = 'bar' is supposed to replace the 'foo' property of
object? This ship sailed a long time ago.
That said, I at least agree that this should be handled with caution.
Changing the 'set' handler seems more related with the 'boxing' part of
the proposal (the one not in the RFC), and it's strange to find it here.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
