Re: [PHP-DEV] C++-like function-try-block proposal

  101221
December 2, 2017 20:08 enclaved@Safe-mail.net ("Alexei Gerasimov")
> It would blur the concept of a function body scope, and thus the mental model of how the language works. > E.g. are local variables and parameters shared between the try {} and the catch {} block?
PHP documentation stresses it that the scope is always the entire function, i.e. it isn't like C/C++ where each compound statement makes up a new scope. The construct may indeed look alien to those who haven't had experience with C++, however, I believe this is a matter of a single clarification statement about scope, plus a tip like "just think of it as if wrapping curly braces are there around it, implicitly" (which is in fact the case), and soon you'll find yourself comfortable with it.
> It would also mean that userland PHP parsers and IDEs need to support the syntax.
True. However, this is true for pretty much any language change, and PHP has seen quite a few lately (typehints, anonymous classes.) I don't think we should be worried about changes _other_ projects would have to make to cope up with language evolution lest it becomes an (unnecessary and surrogate) obstacle. My vision is that if some company/group produces an IDE, it is but natural to expect them to be ready to adapt to language changes.
  101222
December 2, 2017 20:14 theanomaly.is@gmail.com (Sherif Ramadan)
On Sat, Dec 2, 2017 at 3:08 PM, Alexei Gerasimov <enclaved@safe-mail.net>
wrote:

> > I don't think we should be worried about changes _other_ projects would > have to make to cope up with language evolution lest it becomes an > (unnecessary and surrogate) obstacle. My vision is that if some > company/group produces an IDE, it is but natural to expect them to be ready > to adapt to language changes. > > I agree, because our parser is open source like everything else in PHP.
IDEs can likely just generate one from ours with minimal effort. However, it isn't the IDEs I'm worried about. It's the end-users of the language that will struggle the most. Let's not forget PHP 5 has been around for over a decade before PHP 7 even showed up. There are still a lot of old code basis that've been running in PHP 5 for years. And for large code basis with deep rooted legacy, it is no short order to make the leap. Change for the sake of change won't help that.