On Thu, Mar 1, 2012 at 1:45 AM, Clint M Priest <cpri...@zerocue.com> wrote:
> 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 > functions. > In my own advice, this is far more important than every other thing, really. That could require adding __toArray() to ArrayAccess, which would BC break, but that has to be discussed. Why not another RFC about that ? Also, one should keep the past decisions in his head, thus a refreshing about ArrayAccess and current status could be good. Please, see http://devzone.zend.com/1124/zend-weekly-summaries-issue-361/#Heading3 http://devzone.zend.com/284/zend-weekly-summaries-issue-211/#Heading5 for example. My thoughts Julien.P > > I am interested in object natives though, which this is leading in the > direction of. > > -Clint > > -----Original Message----- > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > Sent: Wednesday, February 29, 2012 1:48 AM > To: Anthony Ferrara > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers > > 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 > 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())? > > 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: http://www.php.net/unsub.php > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
