23 ms·

PHP 7.1.0 Released

158 points by ing33k 10y ago

colept 10y ago
Am I alone in thinking that the syntax for nullable types is bizarre? "function example(): string? {" vs "function example() : ?string {"
- ludwigvan 10y ago
  Read "?" as nullable, as in "nullable string".
- skissane 10y ago
  I don't mind it. Think of it this way – ? is a function from types to types. Given type X as input, it returns the union of X and the type of the null value. Once you start thinking of it as function application, putting the symbol which represents the function before the argument seems a perfectly rational thing to do.
  - maweki 10y ago
    That makes it doubly funny since the real reason is that the parser couldn't handle the other case. Even a blind php dev...
    - TazeTSchnitzel 10y ago
      There's nothing wrong with the lexer or the parser. Avoiding becoming like C, where lexical analysis can't be done without knowing context, is a good thing. PHP actually once supported this kind of ambiguity (PHP/FI 2.0 ended PHP code with a single > yet also allowed if ($a > $b)), but this wasn't a good idea and resulted from a greatly suboptimal implementation.
- koenigdavidmj 10y ago
  Last I heard, PHP's lexer and parser do not do well with ambiguity. This is why namespaces use backslash as their separator (since dot and double colon were already taken). Question mark never appeared directly after colon before this, so the second syntax is not ambiguous. The first one would be understood as part of a ternary operator, followed by choking on the start of a block.
  - chris_wot 10y ago
    Should a lexxer and parser "do well" with amiguity ever? I'm not sure I can think of a single one that handles insanely convoluted and ambiguous stuff well at all...
  - TazeTSchnitzel 10y ago
    In PHP, variables, functions, constants and classes are all completely separate namespaces, and likewise methods, properties and static properties are separate namespaces. Reusing :: for namespaces would complicate this. Is foo::bar a class constant or a namespaced constant? Do we autoload src/foo.php or src/foo/bar.php? If I do `new foobar::qux`, is foobar::qux a class, a class constant containing a class name, or a namespaced constant containing a class name? Do we autoload src/foobar.php or src/foobar/qux.php? It's not like the lexer or parser could magically solve this. The way the language is designed, there is inherent ambiguity here. In some other languages, there is a unified symbol table, so you don't have this problem. But PHP doesn't have that.
- nikic 10y ago
  Copy-pasting from an answer on reddit (https://www.reddit.com/r/PHP/comments/5eu9pc/whats_new_in_php_710/dafopvm/ https://www.reddit.com/r/PHP/comments/5eu9pc/whats_new_in_ph...): Because the alternative conflicts in case we ever introduce generics. Consider <?php new Foo<Bar?> ?>. This could either be a generic instantiation, or it could be the same as <?php ((new Foo) < Bar) ?> ?> (which is how it is currently interpreted -- this is valid PHP code!) Of course, you could specify how this is to be interpreted and implement the necessary parser hacks to make it happen, but it's best to avoid the issue altogether by using ? as a prefix. I assume that this is also the reason why Hack does the same.
- latimer 10y ago
  FWIW, this is the same syntax as JSDoc (http://usejsdoc.org/tags-type.html#overview http://usejsdoc.org/tags-type.html#overview).
knocte 10y ago
facepalm
awestroke 10y ago
I will never seriously consider using php for any new project until they clean up their standard library API, but that will probably never happen (python 3 being a good example of what happens when you drop backwards compat in a major way). Even then, stdio==socket and bloated syntax might still weight it down too much. I started my career with PHP, it really is a bummer that it seems destined for the language graveyard
- gog 10y ago
  You can find a thing you don't like in any language. Saying PHP is destined for the "language graveyard" is just spreading FUD around a language that made miraculous improvements in a last couple of years. Both in terms of speed and language features. Modern PHP is a joy to work with.
  - allan_s 10y ago
    yes especially if you take in account that the active support for php5.6 will end in less than a month, and secury patches in 2 years (which is not that long in a career time), it will be more and more feasible to have your work "zen garden" full php7 if you want.
  - rbanffy 10y ago
    > Modern PHP is a joy to work with. Would you clarify that? I've not followed PHPs evolution but it never struck me as a particularly notable language except for the fact it used to be the easiest/cheapest to deploy apps for.
    - coldtea 10y ago
      It gotten tons of syntactic improvements and bells and whistles after version 5. It got a proper, rewritten, parser. It got a free-double-the-speed update for almost all working code in version 7. It got a full featured package manager (composer). It got many next-generation frameworks and libs that don't fall prey to the issues that plagued early PHP codebases. It got the "share nothing" model correctly from the beginning. It's still the easiest and cheapest to deploy, and has tons of extensions for everything. There's active work for a JIT and async (a la Node/Tornado etc) hooks.
lucb1e 10y ago
The removal of hashing from session generation worries me a little for two reasons: 1. The name might not be the most respected one after events, but the work he did and the technical points he made are entirely unaffected. In the light of Snowden revelations and NSA backdoors, Jacob Appelbaum once proposed a drinking game where you read RFCs and every time you encounter a requirement of putting random bytes "on the wire", you drink. Now the NSA might or might not have been able to backdoor all common PRNGs, but Dual EC DRBG was one good example. There's just no good reason not to use hashing before outputting raw bytes other than the reason they removed it from PHP: "less complexity" and improved performance. Then again, in PHP the method was quite complicated with too many tweak options. 2. What if no CSPRNG is available? They seem to fall back and just "read 60 bytes extra for faulty PRNGs", which to my knowledge does not help much in preventing predictability. With a bit of bad luck, this would make sessions entirely predictable. I really wonder whether they couldn't have kept a single hashing algo in with good defaults, rather than allowing to tweak this stuff. That would have been a big speedup and complexity removal already.
- deleted 10y ago
  [deleted]
- dom0 10y ago
  > The name might not be the most respected one after events, but the work he did and the technical points he made are entirely unaffected. Could you please avoid speaking in riddles?
  - lucb1e 10y ago
    If you can specify what exactly is unclear, I might be able to clarify something...
    - extra88 10y ago
      Who is "the name," who is the "he" you're referring to in that sentence?
Jahak 10y ago
Coool
allan_s 10y ago
The addition of the nullable type is really what is going to make the type annotation useful, most of the time you were obliged to drop them because at the very beginning the attribute value was null and so your getters were unable to provide a type annotation, as if your framework was using the newly created objects to let's say generate a html form, you were screwed. I think it will permits for a much better static analysis "a la hack", that will catch all the 'you haven't test for null'.
- aindhaden 10y ago
  Unfortunately they decided to go with explicit nullables instead of implicit, which means that you still have to go and write/modify all your code explicitly to benefit from this. Which pretty much negates the benefit. Implicit nullables across the board are extremely useful when designing loose-coupled and natively unit-testable code. They allow you to design code paths with a minimum of fuss (don't worry about a parameter if you're not actually using it right now), they allow you to substitue simple nulls instead of mocks, and can help to deep-map code paths and use cases for specific parameters. Another issue is the inconsistent manner of dealing with errors generated when attempting to use a parameter as its actual non-null type. They range from notices to fatal errors (non-catchable with try). By contrast, in Java you consistently get a "null pointer exception" when this happens (and Java also has implicit nullables).
  - dom0 10y ago
    Implicit nulls are the so-called "billion dollar" mistake in Java that has been worked around and tried to be fixed in almost every other JVM language. That the PHP folks did not repeat the same mistake might suggest that they, after all, are not the worst language designers (anymore?).
    - deleted 10y ago
      [deleted]
    - aindhaden 10y ago
      I suspect we may be talking about two different approaches. Nobody _wants_ to trip on a null reference, naturally. But there are different ways of achieving that, and some of them yield additional benefits. One way is to forbid them outright (which is what Tony Hoare regretted not doing when he made the "billion dollar mistake" presentation IIRC). Allowing them to run unchecked is obviously not a good idea. The "null object pattern" is another option, where the nulled var will be replaced on the fly with a "mock" that will not cause any trouble. Here's another approach. It's more convoluted and you need the language to help you with it (Java does), but it return it offers the benefits described in my previous post: * Implicit nulls across the board. * No penalty if the nulled variable is not used in an ambiguous manner (passing-on and checking the reference are ok). * Consistent runtime fail-fast behavior if the nulled variable is used in a manner that requires the declared type. (Java throws an exception, which uncaught leads to the stop of the program, thus preventing undefined behavior, but also allows the programmer to catch and recover.) * Most importantly: you DO NOT check for nulls with inline checks or assertions, but instead rely on unit tests to validate intended behavior. The technique is called "passing nulls" in UT. The end result is a more "relaxed" code, which promotes loose coupling and leads to more flexible code paths, which in turn make possible additional patterns. If you're not hurting anything by nulls why be forced to conform to rigid declarations? And if you are hurting something, then you will be forced to deal with it in a consistent manner.
markharris99 10y ago
Not to derail the thread at all. But, for a brand new greenfield application. Why would someone choose PHP for their backend, when Golang is available? I was at a developer meeting with a company who were reviewing what to use for a client project. The developers are from PHP/jQuery shop, however they felt it necessary to be with the times so to speak, for the future to get other projects. They opted for Vuejs and Golang with server side processing. Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow with their own internal testing. Many thanks!
- tonyjstark 10y ago
  You would probably choose PHP because - it's easier to find PHP programmers - you get a lot of mature frameworks with huge communities - most of the time you don't need fast but fast enough just some of the reasons, PHP7 is actually quite nice.
- pearjuice 10y ago
  Because in PHP, you can actually pinpoint dependencies on a specific version.
- kyriakos 10y ago
  Your last sentence really doesn't leave much of a choice.
  - smcl 10y ago
    Guess that depends on whether you take the client's word at face value. If they've done the necessary profiling and analysis, sure - but if not it's also possible they're performance constrained by their DB layer or some badly structured code. No way for me to know though, of course :)
- ceejay 10y ago
  I'd say probably a large part of the reason PHP devs opt to use different languages in new projects (when given the choice) is because of FUD spread about PHP. Everyone wants stability in their career. If the voices on the interweb are loud enough saying PHP is dead / dying, it kind of becomes a self-fulfilling prophecy. I would hazard a guess that if PHP was not so hated (like the one kid on the playground that everyone decides to mock because everyone else is, and because it keeps attention off of them) devs who are familiar with and articulate in PHP would not hesitate to start new projects with it. Anyways, my personal perspective is server-side is becoming a smaller and smaller piece of the web. Any reasonably designed language should be sufficient. Unless maybe if you're Google or Microsoft, or deal heavily with extremely large datasets such as BigData / Analytics / Machine Learning companies. And even then worst case scenario you just throw all the data into AWS RedShift or something like that. If you're writing an OS, building a Linux driver or writing a memory management library I'd certainly recommend avoiding PHP :) BTW, I've run side projects where PHP (before 7.*) sufficiently handled databases with 100's of tables containing billions (yes, that's a 'B') of rows each on a single $250 laptop. That includes jobs running relatively heavy analytics jobs on those tables. My guess is if the company was spending money to get appropriate talent to handle their infrastructure they might be able to make PHP work well for them without a lot of trouble. And by that I don't necessarily mean they have untalented people. I'm saying if they're truly "fluent" in PHP, or are willing to put in the effort to learn PHP, it shouldn't be hard to do.
egeozcan 10y ago
Why can't they just start supporting a new extension that is pure PHP and both ways compatible? Like, no template tags, no global weirdly named functions (namespaces!) and a total cleanup of the library? Also maybe drop the $ and use def or let or whatever? Perhaps add a tool to bundle the script with the interpreter, for reliable deployments? You know, for when you grow out of the "shared hosting" phase? That is MUCH but why not on the very long term? One can dream. Something like a disclaimer: Last time I seriously used PHP, rumors said that PHP 6 was going to be big. I actually fiddled a bit with PHP 7 too. I wrote a file sharing script (incredibly messy code because the minutes I spent on it are in the same order of magnitude of those I spent on this comment), which turned out to be damn fast and I am impressed. Saying this as a person who enjoys Rust and Go.
- kyriakos 10y ago
  It improved a lot since then, maybe you should give it another go. Both the actual language and the ecosystem around it evolved considerably since the times you describe.
- Mahn 10y ago
  > no template tags Why? Native PHP excels at html templating, that's what it was created for.
  - scintill76 10y ago
    Native templating isn't easy/safe. Every time you want to embed a dynamic string, you'd better remember to escape it in the correct way for the context (attribute value, text, JSON), or you're vulnerable to HTML injection, or at least mangled output that doesn't render the way it should have. If they built syntax-aware templating in, that might be interesting, but AFAIK, for now you have to use a third-party template implementation to get something semi-enjoyable to use safely. It would be better to just throw out the "template" features because they encourage messy, unsafe code.
    - tyingq 10y ago
      As far as I know, most templating frameworks (php or otherwise) don't really solve this either. PHP's native templating is perhaps prone to more issues in this area, but template frameworks (for the most part) still allow you shoot yourself in the foot with data contained in strings.
gtbono 10y ago
Does this have any chance of being included in the next Debian release? (Stretch) It is starting to prepare for freeze, dunno if there is still time
philjohn 10y ago
Wow ... stas seems to always vote against things that are pulling PHP into being a much more rounded language, I wonder why that is?
synacksa 10y ago
I've been waiting for 7.1 so that I can start implementing return typing. It seemed very limited that I couldn't return null's before, so I didn't really bother with it.

158 points by ing33k 10y ago

Am I alone in thinking that the syntax for nullable types is bizarre? "function example(): string? {" vs "function example() : ?string {"

ludwigvan 10y ago
Read "?" as nullable, as in "nullable string".
skissane 10y ago
I don't mind it. Think of it this way – ? is a function from types to types. Given type X as input, it returns the union of X and the type of the null value. Once you start thinking of it as function application, putting the symbol which represents the function before the argument seems a perfectly rational thing to do.
- maweki 10y ago
  That makes it doubly funny since the real reason is that the parser couldn't handle the other case. Even a blind php dev...
  - TazeTSchnitzel 10y ago
    There's nothing wrong with the lexer or the parser. Avoiding becoming like C, where lexical analysis can't be done without knowing context, is a good thing. PHP actually once supported this kind of ambiguity (PHP/FI 2.0 ended PHP code with a single > yet also allowed if ($a > $b)), but this wasn't a good idea and resulted from a greatly suboptimal implementation.
koenigdavidmj 10y ago
Last I heard, PHP's lexer and parser do not do well with ambiguity. This is why namespaces use backslash as their separator (since dot and double colon were already taken). Question mark never appeared directly after colon before this, so the second syntax is not ambiguous. The first one would be understood as part of a ternary operator, followed by choking on the start of a block.
- chris_wot 10y ago
  Should a lexxer and parser "do well" with amiguity ever? I'm not sure I can think of a single one that handles insanely convoluted and ambiguous stuff well at all...
- TazeTSchnitzel 10y ago
  In PHP, variables, functions, constants and classes are all completely separate namespaces, and likewise methods, properties and static properties are separate namespaces. Reusing :: for namespaces would complicate this. Is foo::bar a class constant or a namespaced constant? Do we autoload src/foo.php or src/foo/bar.php? If I do `new foobar::qux`, is foobar::qux a class, a class constant containing a class name, or a namespaced constant containing a class name? Do we autoload src/foobar.php or src/foobar/qux.php? It's not like the lexer or parser could magically solve this. The way the language is designed, there is inherent ambiguity here. In some other languages, there is a unified symbol table, so you don't have this problem. But PHP doesn't have that.
nikic 10y ago
Copy-pasting from an answer on reddit (https://www.reddit.com/r/PHP/comments/5eu9pc/whats_new_in_php_710/dafopvm/ https://www.reddit.com/r/PHP/comments/5eu9pc/whats_new_in_ph...): Because the alternative conflicts in case we ever introduce generics. Consider <?php new Foo<Bar?> ?>. This could either be a generic instantiation, or it could be the same as <?php ((new Foo) < Bar) ?> ?> (which is how it is currently interpreted -- this is valid PHP code!) Of course, you could specify how this is to be interpreted and implement the necessary parser hacks to make it happen, but it's best to avoid the issue altogether by using ? as a prefix. I assume that this is also the reason why Hack does the same.
latimer 10y ago
FWIW, this is the same syntax as JSDoc (http://usejsdoc.org/tags-type.html#overview http://usejsdoc.org/tags-type.html#overview).

knocte 10y ago

facepalm

awestroke 10y ago

I will never seriously consider using php for any new project until they clean up their standard library API, but that will probably never happen (python 3 being a good example of what happens when you drop backwards compat in a major way). Even then, stdio==socket and bloated syntax might still weight it down too much. I started my career with PHP, it really is a bummer that it seems destined for the language graveyard

gog 10y ago
You can find a thing you don't like in any language. Saying PHP is destined for the "language graveyard" is just spreading FUD around a language that made miraculous improvements in a last couple of years. Both in terms of speed and language features. Modern PHP is a joy to work with.
- allan_s 10y ago
  yes especially if you take in account that the active support for php5.6 will end in less than a month, and secury patches in 2 years (which is not that long in a career time), it will be more and more feasible to have your work "zen garden" full php7 if you want.
- rbanffy 10y ago
  > Modern PHP is a joy to work with. Would you clarify that? I've not followed PHPs evolution but it never struck me as a particularly notable language except for the fact it used to be the easiest/cheapest to deploy apps for.
  - coldtea 10y ago
    It gotten tons of syntactic improvements and bells and whistles after version 5. It got a proper, rewritten, parser. It got a free-double-the-speed update for almost all working code in version 7. It got a full featured package manager (composer). It got many next-generation frameworks and libs that don't fall prey to the issues that plagued early PHP codebases. It got the "share nothing" model correctly from the beginning. It's still the easiest and cheapest to deploy, and has tons of extensions for everything. There's active work for a JIT and async (a la Node/Tornado etc) hooks.

lucb1e 10y ago

The removal of hashing from session generation worries me a little for two reasons: 1. The name might not be the most respected one after events, but the work he did and the technical points he made are entirely unaffected. In the light of Snowden revelations and NSA backdoors, Jacob Appelbaum once proposed a drinking game where you read RFCs and every time you encounter a requirement of putting random bytes "on the wire", you drink. Now the NSA might or might not have been able to backdoor all common PRNGs, but Dual EC DRBG was one good example. There's just no good reason not to use hashing before outputting raw bytes other than the reason they removed it from PHP: "less complexity" and improved performance. Then again, in PHP the method was quite complicated with too many tweak options. 2. What if no CSPRNG is available? They seem to fall back and just "read 60 bytes extra for faulty PRNGs", which to my knowledge does not help much in preventing predictability. With a bit of bad luck, this would make sessions entirely predictable. I really wonder whether they couldn't have kept a single hashing algo in with good defaults, rather than allowing to tweak this stuff. That would have been a big speedup and complexity removal already.

deleted 10y ago
[deleted]
dom0 10y ago
> The name might not be the most respected one after events, but the work he did and the technical points he made are entirely unaffected. Could you please avoid speaking in riddles?
- lucb1e 10y ago
  If you can specify what exactly is unclear, I might be able to clarify something...
  - extra88 10y ago
    Who is "the name," who is the "he" you're referring to in that sentence?

Jahak 10y ago

Coool

allan_s 10y ago

The addition of the nullable type is really what is going to make the type annotation useful, most of the time you were obliged to drop them because at the very beginning the attribute value was null and so your getters were unable to provide a type annotation, as if your framework was using the newly created objects to let's say generate a html form, you were screwed. I think it will permits for a much better static analysis "a la hack", that will catch all the 'you haven't test for null'.

aindhaden 10y ago
Unfortunately they decided to go with explicit nullables instead of implicit, which means that you still have to go and write/modify all your code explicitly to benefit from this. Which pretty much negates the benefit. Implicit nullables across the board are extremely useful when designing loose-coupled and natively unit-testable code. They allow you to design code paths with a minimum of fuss (don't worry about a parameter if you're not actually using it right now), they allow you to substitue simple nulls instead of mocks, and can help to deep-map code paths and use cases for specific parameters. Another issue is the inconsistent manner of dealing with errors generated when attempting to use a parameter as its actual non-null type. They range from notices to fatal errors (non-catchable with try). By contrast, in Java you consistently get a "null pointer exception" when this happens (and Java also has implicit nullables).
- dom0 10y ago
  Implicit nulls are the so-called "billion dollar" mistake in Java that has been worked around and tried to be fixed in almost every other JVM language. That the PHP folks did not repeat the same mistake might suggest that they, after all, are not the worst language designers (anymore?).
  - deleted 10y ago
    [deleted]
  - aindhaden 10y ago
    I suspect we may be talking about two different approaches. Nobody _wants_ to trip on a null reference, naturally. But there are different ways of achieving that, and some of them yield additional benefits. One way is to forbid them outright (which is what Tony Hoare regretted not doing when he made the "billion dollar mistake" presentation IIRC). Allowing them to run unchecked is obviously not a good idea. The "null object pattern" is another option, where the nulled var will be replaced on the fly with a "mock" that will not cause any trouble. Here's another approach. It's more convoluted and you need the language to help you with it (Java does), but it return it offers the benefits described in my previous post: * Implicit nulls across the board. * No penalty if the nulled variable is not used in an ambiguous manner (passing-on and checking the reference are ok). * Consistent runtime fail-fast behavior if the nulled variable is used in a manner that requires the declared type. (Java throws an exception, which uncaught leads to the stop of the program, thus preventing undefined behavior, but also allows the programmer to catch and recover.) * Most importantly: you DO NOT check for nulls with inline checks or assertions, but instead rely on unit tests to validate intended behavior. The technique is called "passing nulls" in UT. The end result is a more "relaxed" code, which promotes loose coupling and leads to more flexible code paths, which in turn make possible additional patterns. If you're not hurting anything by nulls why be forced to conform to rigid declarations? And if you are hurting something, then you will be forced to deal with it in a consistent manner.

markharris99 10y ago

Not to derail the thread at all. But, for a brand new greenfield application. Why would someone choose PHP for their backend, when Golang is available? I was at a developer meeting with a company who were reviewing what to use for a client project. The developers are from PHP/jQuery shop, however they felt it necessary to be with the times so to speak, for the future to get other projects. They opted for Vuejs and Golang with server side processing. Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow with their own internal testing. Many thanks!

tonyjstark 10y ago
You would probably choose PHP because - it's easier to find PHP programmers - you get a lot of mature frameworks with huge communities - most of the time you don't need fast but fast enough just some of the reasons, PHP7 is actually quite nice.
pearjuice 10y ago
Because in PHP, you can actually pinpoint dependencies on a specific version.
kyriakos 10y ago
Your last sentence really doesn't leave much of a choice.
- smcl 10y ago
  Guess that depends on whether you take the client's word at face value. If they've done the necessary profiling and analysis, sure - but if not it's also possible they're performance constrained by their DB layer or some badly structured code. No way for me to know though, of course :)
ceejay 10y ago
I'd say probably a large part of the reason PHP devs opt to use different languages in new projects (when given the choice) is because of FUD spread about PHP. Everyone wants stability in their career. If the voices on the interweb are loud enough saying PHP is dead / dying, it kind of becomes a self-fulfilling prophecy. I would hazard a guess that if PHP was not so hated (like the one kid on the playground that everyone decides to mock because everyone else is, and because it keeps attention off of them) devs who are familiar with and articulate in PHP would not hesitate to start new projects with it. Anyways, my personal perspective is server-side is becoming a smaller and smaller piece of the web. Any reasonably designed language should be sufficient. Unless maybe if you're Google or Microsoft, or deal heavily with extremely large datasets such as BigData / Analytics / Machine Learning companies. And even then worst case scenario you just throw all the data into AWS RedShift or something like that. If you're writing an OS, building a Linux driver or writing a memory management library I'd certainly recommend avoiding PHP :) BTW, I've run side projects where PHP (before 7.*) sufficiently handled databases with 100's of tables containing billions (yes, that's a 'B') of rows each on a single $250 laptop. That includes jobs running relatively heavy analytics jobs on those tables. My guess is if the company was spending money to get appropriate talent to handle their infrastructure they might be able to make PHP work well for them without a lot of trouble. And by that I don't necessarily mean they have untalented people. I'm saying if they're truly "fluent" in PHP, or are willing to put in the effort to learn PHP, it shouldn't be hard to do.

egeozcan 10y ago

Why can't they just start supporting a new extension that is pure PHP and both ways compatible? Like, no template tags, no global weirdly named functions (namespaces!) and a total cleanup of the library? Also maybe drop the $ and use def or let or whatever? Perhaps add a tool to bundle the script with the interpreter, for reliable deployments? You know, for when you grow out of the "shared hosting" phase? That is MUCH but why not on the very long term? One can dream. Something like a disclaimer: Last time I seriously used PHP, rumors said that PHP 6 was going to be big. I actually fiddled a bit with PHP 7 too. I wrote a file sharing script (incredibly messy code because the minutes I spent on it are in the same order of magnitude of those I spent on this comment), which turned out to be damn fast and I am impressed. Saying this as a person who enjoys Rust and Go.

kyriakos 10y ago
It improved a lot since then, maybe you should give it another go. Both the actual language and the ecosystem around it evolved considerably since the times you describe.
Mahn 10y ago
> no template tags Why? Native PHP excels at html templating, that's what it was created for.
- scintill76 10y ago
  Native templating isn't easy/safe. Every time you want to embed a dynamic string, you'd better remember to escape it in the correct way for the context (attribute value, text, JSON), or you're vulnerable to HTML injection, or at least mangled output that doesn't render the way it should have. If they built syntax-aware templating in, that might be interesting, but AFAIK, for now you have to use a third-party template implementation to get something semi-enjoyable to use safely. It would be better to just throw out the "template" features because they encourage messy, unsafe code.
  - tyingq 10y ago
    As far as I know, most templating frameworks (php or otherwise) don't really solve this either. PHP's native templating is perhaps prone to more issues in this area, but template frameworks (for the most part) still allow you shoot yourself in the foot with data contained in strings.

gtbono 10y ago

Does this have any chance of being included in the next Debian release? (Stretch) It is starting to prepare for freeze, dunno if there is still time

philjohn 10y ago

Wow ... stas seems to always vote against things that are pulling PHP into being a much more rounded language, I wonder why that is?

synacksa 10y ago

I've been waiting for 7.1 so that I can start implementing return typing. It seemed very limited that I couldn't return null's before, so I didn't really bother with it.