On 2012-04-13, Nicolas Grekas <nicolas.grekas+...@gmail.com> wrote:
> > Yes, the original used "$this->getFooBar()" -- but it could have been
> > "$someOtherObject->getFooBar()"
>
> Yep, you and Anthony are right, my comment was stupid...
>
> Then I have an other objection :)
>
> I'm not comfortable with mixing declarative lines with expressions:
> function (..) use (..) is always purely declarative, whatever the (..)
> but
> function (..) use ((expression) as $foo) isn't any more.
>
> I would feel the same e.g. with a syntax like:
> function ($a = $foo->bar()) {} (a closure with default argument calculated
> once but give as expression.)
>
> If you like "use ((expr) as $foo)", do you like the above?
> This is an open question, a yes would be coherent,
> but otherwise, why allow one and not the other?
No -- because you can't do it when declaring a normal function
(non-closure/lambda/anonymous). If we could do that syntax with regular
function/method declarations:
// lazy-create $foo if not passed
public function doSomething(FooBar $foo = new FooBar())
it _might_ make sense, but as it stands, it's inconsistent with how we
allow function declarations.
I'm on the fence about "use ((expression) as $foo)" -- I fully like the
idea of aliasing closure variables, but still thinking on the expression
syntax. It would be _inconsistent_ with how it works with namespaces
(which uses literals only), and _semi-consistent_ with traits (which
have the "insteadof" syntax). I can definitely think of some nice use
cases surrounding them, though.
--
Matthew Weier O'Phinney
Project Lead | matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
