Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58374
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 74.115.204.51 as permitted sender)
To: Stas Malyshev <smalyshev@sugarcrm.com>, Anthony Ferrara
	<ircmaxell@gmail.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Thread-Index: AQHM9ouO4T9lhxwTgEKe+ybxkU+eqZZT062AgADHTfA=
Date: Thu, 1 Mar 2012 00:45:19 +0000
Message-ID: <9570D903A3BECE4092E924C2985CE485515FC4EC@MBX202.domain.local>
References: <CAAyV7nFDzV=V+yGCWmJiaOELMdQzdpT1UCvqkkM-o9-Ehy+K2w@mail.gmail.com>
 <4F4DD837.9090705@sugarcrm.com>
In-Reply-To: <4F4DD837.9090705@sugarcrm.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
From: cpriest@zerocue.com (Clint M Priest)

As much as I would love to have __castTo() and __assign() I have to agree w=
ith Stas here that it fundamentally changes the mechanics of if($object) an=
d unfortunately turns that simple if statement into a possible hour long hu=
nt to find the code that is doing the damage, if it is even considered a po=
ssibility by someone reading the code.

For the record, I really have only ever needed something like __toArray() s=
o that objects implementing ArrayAccess could be passed to array internal f=
unctions.

I am interested in object natives though, which this is leading in the dire=
ction of.

-Clint

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]=20
Sent: Wednesday, February 29, 2012 1:48 AM
To: Anthony Ferrara
Cc: internals@lists.php.net
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()=20
> 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 ca=
ses where they need to do so transparently are almost non-existent. I think=
 what outlined in the RFC is a backdoor operator overloading, through rathe=
r complex and unobvious magic. My opinion is that outside of very limited n=
umber of cases (such as implementing complex numbers or matrix algebra - an=
d how frequently would one need do that in PHP anyway?) operator overloadin=
g is way more trouble than it's worth and makes code nearly unreadable as y=
ou never know what exactly each operator does. For example, if($object) wou=
ld have completely different semantics than before, for some objects but no=
t other, and without any obvious clue to the user what it actually does - a=
nd 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 SplFixed=
Array 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 =3D {expression} =
is supposed to replace $obj with the result of the expression, not call met=
hods on $obj. Doing otherwise would be huge change in the semantics, a comp=
lete no go. Also, it's impossible if $obj is not set - meaning, code $obj =
=3D 1 would mean totally different things depending on if $obj is set or no=
t - 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 assign=
ment seems very wrong to me in principle, so no need to go into the fine de=
tails.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:=
 http://www.php.net/unsub.php