Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: jpauli <jpauli <at> php.net>
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Newsgroups: gmane.comp.php.devel
Date: Thursday 1st March 2012 10:40:04 UTC (over 4 years ago)
On Thu, Mar 1, 2012 at 1:45 AM, Clint M Priest  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:[email protected]]
> Sent: Wednesday, February 29, 2012 1:48 AM
> To: Anthony Ferrara
> Cc: [email protected]
> 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
>
>
 
CD: 2ms