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