Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58339
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.173 as permitted sender)
Message-ID: <4F4E6168.4080502@sugarcrm.com>
Date: Wed, 29 Feb 2012 09:33:28 -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> <4F4DD837.9090705@sugarcrm.com> <CAAyV7nFg+XdK34pfhidZ9xov7X=6RPzE83z1-KuvEuHGHgN=Cg@mail.gmail.com>
In-Reply-To: <CAAyV7nFg+XdK34pfhidZ9xov7X=6RPzE83z1-KuvEuHGHgN=Cg@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!

>> 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.
>
> The engine already calls methods on $obj when that happens.  That's
> the set handler.  It just happens that user classes have a null set
> handler, which is why it works the way it does.  Internal classes have
> full ability to work this way...

This is internal implementation detail. Having it in the guts of the 
engine is one thing, exposing it to the user is quite another. The 
engine can also access arbitrary memory addresses and write arbitrary 
data there, but we don't propose to let the user do the same in PHP.

> Pedantic note: It already means different things.  We have notices if
> it's not set, and it behaves differently if references are involved.
> So already we have a few different effects on what happens depending
> on where and how $obj was defined.  So I fail to see how this is
> *that* much of a shift.

Again, you seem to miss important differences here. Providing notices 
when something is wrong in the expression is one thing, changing 
semantics of assignment is quite another. Saying "because we have 
notices it's also OK to have completely different semantics" makes very 
little sense to me.

> really what it can enable is really powerful.  Additionally, the code
> is already there, and there are already classes using that code
> (SimpleXML for one).  So it's not like it's introducing new
> functionality, it's just exposing the existing functionality to be
> leveraged by PHP land code...

SimpleXML does not change semantics of assignment. It uses some engine 
trickery to achieve what it does but the semantics exposed to the user 
is simple and intuitive. You propose to create ability to introduce 
semantics which in its intended usage will be both counterintuitive and 
disagreeing with how the engine works now.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227