Features Download
From: Clint M Priest <cpriest <at> zerocue.com>
Subject: RE: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Newsgroups: gmane.comp.php.devel
Date: Thursday 1st March 2012 00:45:19 UTC (over 6 years ago)
As much as I would love to have __castTo() and __assign() I have to agree
with Stas here that it fundamentally changes the mechanics of if($object)
and unfortunately turns that simple if statement into a possible hour long
hunt to find the code that is doing the damage, if it is even considered a
possibility by someone reading the code.

For the record, I really have only ever needed something like __toArray()
so that objects implementing ArrayAccess could be passed to array internal

I am interested in object natives though, which this is leading in the
direction of.


-----Original Message-----
From: Stas Malyshev [mailto:[email protected]] 
Sent: Wednesday, February 29, 2012 1:48 AM
To: Anthony Ferrara
Cc: [email protected]
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers


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

Still, if there's a valid use case found, cast magic method and "unboxing"
method may have merit. So far the cases outlined seem either too artificial
and narrow for language-level functionality, or plain wrong (like
SplFixedArray example - nothing in this proposal would enable it to work
with sort, for example). But I do not exclude other cases can exist.

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. Also, it's impossible if $obj is not set - meaning, code
$obj = 1 would mean totally different things depending on if $obj is set or
not - again, not a good idea. It also does not cover many corner cases but
I don't even want to go there since an idea to change semantics of the
assignment seems very wrong to me in principle, so no need to go into the
fine details.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
CD: 17ms