jpauli | 1 Mar 11:40 2012

Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers

On Thu, Mar 1, 2012 at 1:45 AM, Clint M Priest <cpriest <at>> 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  for

My thoughts


> I am interested in object natives though, which this is leading in the
> direction of.
> -Clint
> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev <at>]
> Sent: Wednesday, February 29, 2012 1:48 AM
> To: Anthony Ferrara
> Cc: internals <at>
> 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():
> >
> >
> 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:
> (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: