Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58320
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.163 as permitted sender)
Message-ID: <4F4DD837.9090705@sugarcrm.com>
Date: Tue, 28 Feb 2012 23:48:07 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAAyV7nFDzV=V+yGCWmJiaOELMdQzdpT1UCvqkkM-o9-Ehy+K2w@mail.gmail.com>
In-Reply-To: <CAAyV7nFDzV=V+yGCWmJiaOELMdQzdpT1UCvqkkM-o9-Ehy+K2w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
From: smalyshev@sugarcrm.com (Stas Malyshev)

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