Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58329
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.113 as permitted sender)
Message-ID: <4F4DF0A2.7090904@sugarcrm.com>
Date: Wed, 29 Feb 2012 01:32:18 -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: Gustavo Lopes <glopes@nebm.ist.utl.pt>
CC: Anthony Ferrara <ircmaxell@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAAyV7nFDzV=V+yGCWmJiaOELMdQzdpT1UCvqkkM-o9-Ehy+K2w@mail.gmail.com> <4F4DD837.9090705@sugarcrm.com> <op.wafmqitcidpuyk@slws007.slhq.int>
In-Reply-To: <op.wafmqitcidpuyk@slws007.slhq.int>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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.

This all can be (and is) done with engine-level hooks. As I noted in my 
previous mail, most RFC examples are either exotic (like limited-range 
integers) or wrong (like SplFixedArray). Bigint objects are a good case, 
but it won't work without proper operator overloading (as scalar + would 
not support all values) and operator overloading on PHP level is too 
dangerous. On engine level it may be viable, but that's another can of 
worms.

> 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

So how it's not operator overloading? It changes semantics of + to do 
unobvious magic. Granted, the magic is limited, but it's still unobvious 
magic. Even then, I could probably see it being done, if there's some 
good use cases - meaning something that a) is needed by many users (not 
just "it's be cool if we could pull of this trick just for the fun of 
it") b) without it doing the same is substantially harder.

> Just like $a->foo = 'bar' is supposed to replace the 'foo' property of
> object? This ship sailed a long time ago.

No it did not. Overriding object access for some specific object to do 
set operation is one thing, changing semantics of a basic assignment 
operation is another. BTW, what exactly $a->foo = 'bar' supposed to do 
here according to RFC? Call __get and call __assign on the result or 
call __set? You see how this magic becomes unmanageable.

> That said, I at least agree that this should be handled with caution.

I would replace "caution" with "ten foot pole". I do not see how 
changing general semantics of assignment can lead to anything good. 
Especially in PHP where the code is supposed to be readable by 
relatively unsophisticated users (and yes, that means you should avoid 
"creative" get/sets too btw, but since most use cases do what user 
thinks they will we don't have a problem). When I can't know what $obj = 
1; does it's not a good idea.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227