Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56697 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62578 invoked from network); 1 Dec 2011 04:20:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Dec 2011 04:20:48 -0000 X-Host-Fingerprint: 208.107.21.52 host-52-21-107-208.midco.net Date: Wed, 30 Nov 2011 23:20:48 -0500 Received: from [208.107.21.52] ([208.107.21.52:7666] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 66/80-56905-F9007DE4 for ; Wed, 30 Nov 2011 23:20:48 -0500 Message-ID: <66.80.56905.F9007DE4@pb1.pair.com> To: internals@lists.php.net References: <4ED6713D.2050009@ralphschindler.com> <4ED67DCB.5090102@ralphschindler.com> <4ED68940.3050502@ralphschindler.com> <90D867E2-E6FB-481D-B57C-911E5FE6A418@gmail.com> User-Agent: slrn/pre1.0.0-18 (Linux) X-Posted-By: 208.107.21.52 Subject: Re: [PHP-DEV] 5.4's New De-referencing plus assignment From: weierophinney@php.net (Matthew Weier O'Phinney) On 2011-11-30, Will Fitch 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 >>> 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