Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58406
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
Received-SPF: pass (google.com: domain of julienpauli@gmail.com designates 10.213.105.70 as permitted sender) client-ip=10.213.105.70;
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <9570D903A3BECE4092E924C2985CE485515FC4EC@MBX202.domain.local>
References: <CAAyV7nFDzV=V+yGCWmJiaOELMdQzdpT1UCvqkkM-o9-Ehy+K2w@mail.gmail.com>
 <4F4DD837.9090705@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485515FC4EC@MBX202.domain.local>
Date: Thu, 1 Mar 2012 11:40:04 +0100
Message-ID: <CAMUwpuTda+65i-HMgvkUhBYqVHOgM=PSXGgKC57ct5aKPMVpZw@mail.gmail.com>
To: Clint M Priest <cpriest@zerocue.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Anthony Ferrara <ircmaxell@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0015174c4152a29e1404ba2c178d
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
From: jpauli@php.net (jpauli)

--0015174c4152a29e1404ba2c178d
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 1, 2012 at 1:45 AM, Clint M Priest <cpriest@zerocue.com> wrote:

> As much as I would love to have __castTo() and __assign() I have to agree
> with Stas here that it fundamentally changes the mechanics of if($object)
> and unfortunately turns that simple if statement into a possible hour long
> hunt to find the code that is doing the damage, if it is even considered a
> possibility by someone reading the code.
>
> For the record, I really have only ever needed something like __toArray()
> so that objects implementing ArrayAccess could be passed to array internal
> functions.
>

In my own advice, this is far more important than every other thing, really.
That could require adding __toArray() to ArrayAccess, which would BC break,
but that has to be discussed. Why not another RFC about that ?

Also, one should keep the past decisions in his head, thus a refreshing
about ArrayAccess and current status could be good.
Please, see
http://devzone.zend.com/1124/zend-weekly-summaries-issue-361/#Heading3
http://devzone.zend.com/284/zend-weekly-summaries-issue-211/#Heading5  for
example.

My thoughts

Julien.P



>
> I am interested in object natives though, which this is leading in the
> direction of.
>
> -Clint
>
> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> 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()
> > 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> visit: http://www.php.net/unsub.php
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0015174c4152a29e1404ba2c178d--