Re: 5.4's New De-referencing plus assignment

From: Date: Thu, 01 Dec 2011 04:20:48 +0000
Subject: Re: 5.4's New De-referencing plus assignment
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-56697@lists.php.net to get a copy of this message
On 2011-11-30, Will Fitch <will.fitch@gmail.com> wrote: > If that's the case, then why not just add whatever $options is as a > parameter to your constructor. I'm not totally against this concept, > but this use is moot. No, it's not. Consider the case of using a variable for the class name -- i.e., dynamic classloading. It's typically bad OOP to have interfaces define the constructor, so you'll identify a method used for configuration. That ends up looking like this: $classname = discover_class_name(); ($foo = new $classname())->configure($options); This would work, as you expect the class to conform to an interface that defines configure(). > On Nov 30, 2011, at 2:51 PM, Ralph Schindler wrote: > >> Ironically, quite the opposite is something I find useful: >> >> ($foo = new MyComponent($bar))->configure($options); >> >> In a single line, instantiate and configure (via an API call) an object. The return of >> configure() is not important to me, but the brevity of that workflow, and the result of >> "new" is. >> >> -ralph >> >> >> On 11/30/11 1:13 PM, Nikita Popov wrote: >>> To me the main problem here is that $bar = ($foo = new Foo)->bar() >>> simply doesn't make much sense. It is equivalent to: >>> $foo = new Foo; >>> $bar = $foo->bar(); >>> Which is much cleaner and easier to understand. >>> >>> The plain (new Foo)->bar() syntax *is* useful for cases like (new >>> ReflectionClass($class))->implementsInterface('Foo'), where you need >>> only one single bit of information from a class. >>> >>> Nikita >>> >>> On Wed, Nov 30, 2011 at 8:02 PM, Ralph Schindler >>> <ralph@ralphschindler.com> wrote: >>>> Nikita, >>>> >>>> You're completely right about the expanded expressions, but I'm not sure >>>> its >>>> an edge-case per-se. >>>> >>>> The problem with the current syntax is that the resultant of the 'new' >>>> operation is lost UNLESS your chained method returns $this - which IMO makes >>>> it about as 1/2 as useful as it really could be. >>>> >>>> In the case of "new" though, the resultant is always an object, it seems >>>> like it should be permissible to change the parser to allow for variable >>>> assignment of the target object. >>>> >>>> I think for people just trying out this new behavior (by seeing it in the >>>> release notes as (new Foo)->bar()), the next logical thing is to try this >>>> syntax: >>>> >>>> ($foo = new Foo)->bar() >>>> >>>> // OR in bison >>>> '(' variable '=' new_expr ')' >>>> >>>> I did it, and I see other people doing it too. So I guess the question is... >>>> "how edge case is this edge case?" :) >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

« previous php.internals (#56697) next »