Re: [RFC] Array Dereferencing

From: 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>

« previous php.internals (#48691) next »