Re: [RFC] Array Dereferencing
| From: | Peter Lind | Date: | Tue, 08 Jun 2010 15:20:52 +0000 |
| Subject: | Re: [RFC] Array Dereferencing | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-48691@lists.php.net to get a copy of this message | ||
On 8 June 2010 16:57, Ford, Mike <M.Ford@leedsmet.ac.uk> wrote:
>> -----Original Message-----
>> From: Jacob Oettinger [mailto:jacob@oettinger.dk]
>> Sent: 08 June 2010 14:09
>>
>> On 08/06/2010, at 12.41, Johannes Schlüter wrote:
>>
>> > On Tue, 2010-06-08 at 12:23 +0200, Jacob Oettinger wrote:
>> >> Would it be equally simple to allow the syntax below?
>> >>
>> >> $result = new ResultMaker()->getIt();
>> >
>> > does this mean
>> >
>> > $result = new (ResultMaker()->getIt());
>> >
>> > or
>> >
>> > $result = (new ResultMaker())->getIt();
>> >
>> > I assume the later, but that is non-obvious as we allow
>> >
>> > $result = new $class();
>>
>> Yes the later. I do not see how the above makes it non-obvious.
>
> I think the only problem with deciding which it means is that -> and () are not defined as
> operators in the PHP documentation, and as such do not have a clearly-defined precedence and
> associativity. In Javascript, "." (property access) and "()" (function call)
> both appear in the operator precedence table, so there are definite rules for ascertaining the
> meaning of such a construct.
>
> Up until recently this probably hasn't really been a problem, as it's not been
> possible to write constructs that needed these rules to decipher them.. However, with the previous
> addition of object access chaining, and now array dereferencing, the time has almost certainly come
> to add -> and () to the operator documentation, with appropriate precedence and associativity.
>
> (Incidentally, other operators which are not documented in the "Operators" section,
> and probably should be, include :: (which *is* described in the "Classes and Objects"
> section as the "Scope Resolution Operator", and \ (namespace separator).)
>
The operator that really determines this is 'new' - which is already
documented. So there isn't any ambiguity. Not to say that documenting
the other operators would be bad, just saying there's no ambiguity
here :)
Also, allowing "new (blah());" would be a fairly big BC break I'd say.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>