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.
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
>> <[email protected]> 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
