Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58325
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Anthony Ferrara" <ircmaxell@gmail.com>, "Stas Malyshev"
 <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <CAAyV7nFDzV=V+yGCWmJiaOELMdQzdpT1UCvqkkM-o9-Ehy+K2w@mail.gmail.com> <4F4DD837.9090705@sugarcrm.com>
Date: Wed, 29 Feb 2012 09:48:08 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.wafmqitcidpuyk@slws007.slhq.int>
In-Reply-To: <4F4DD837.9090705@sugarcrm.com>
User-Agent: Opera Mail/11.61 (Win32)
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Wed, 29 Feb 2012 08:48:07 +0100, Stas Malyshev <smalyshev@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