Hi!
> Also one thing not mentioned in the initial letter - this will also allow
> you to use expressions for new operator in the same way: `new
> (str_replace('/', '\\', $classPath))()` - just an example.
OK, if we apply it consistently - i.e. say anywhere that we allow
literal or ${variable-like expression} we also allow (generic
expression) - then it would probably work. I'm still not sure I like it
too much - for instance, if I saw something like the example above in
the code review, I'd ask to rewrite it with a variable, since it's
unreadable and all too easy to make a mistake. Variables are not that
bad, and not everything needs to be a one-liner.
> I would say that it's just not logical to have some operator that can
> accept dynamic (runtime-defined) value but not an expression.
Right now, many constructs do exactly that - they accept literal or
variable (with some stretching of what "variable" is, esp. with uniform
syntax RFC which allows to stuff quite a lot in a variable) but not
generic expression. However, the same uniform variable RFC allows many
operations now to accept expressions via (expression) syntax, so maybe
we can expand on that further and allow this in any context where
literal+variable previously were accepted. I.e. now FOO() accepts FOO
being (expression) but new FOO() does not, which does seem a bit
inconsistent. So maybe it can be done. I'm still not sure personally
doing this is a good thing - it is too easy to make code completely
incomprehensible with this - but maybe I'm wrong here.
I think it may be worth asking Nikita Popov if if it's be feasible to
extend his RFC to these cases.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
