PHP 7.1.0 Released

http://php.net/archive/2016.php#id2016-12-01-3

by ing33k • 10 years ago

158 102 10 years ago

php.net

colept• 10 years ago

Am I alone in thinking that the syntax for nullable types is bizarre?

"function example(): string? {"

"function example() : ?string {"

skissane• 10 years 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• 10 years 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...

koenigdavidmj• 10 years 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_wot2• 10 years 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...

TazeTSchnitzel3• 10 years 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• 10 years ago

Copy-pasting from an answer on reddit (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• 10 years ago

FWIW, this is the same syntax as JSDoc (http://usejsdoc.org/tags-type.html#overview).

ludwigvan• 10 years ago

Read "?" as nullable, as in "nullable string".

knocte• 10 years ago

facepalm

awestroke• 10 years 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• 10 years 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_s2• 10 years 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.

rbanffy2• 10 years 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.

naranha5• 10 years ago

I agree OOP PHP is way to bloated for a dynamic language. Did they have to copy Java?

I feel like PHP5+ was made by Jetbrains to sell their overpriced Web IDE solutions.

alexbilbie• 10 years ago

Could you explain what is bloated about OOP PHP?

coldtea6• 10 years ago

I agree OOP PHP is way to bloated for a dynamic language.

Ever checked Ruby's or Python's feature list? Or ES7 for that matter?

tyingq4• 10 years ago

Did they have to copy Java?

I assume you mean because they both use literal words like "class", "public", "private" in the syntax?

It seems fairly logical to use descriptive syntax to me. See c++, c# as well.

greyman2• 10 years ago

That will never happen, and it would be also a wrong thing to do, as the example of python shows. One of the main strengths of PHP is a low barrier of entry, which also includes things like you google how to do something, and what you googled indeed works. This is often true for PHP. Nothing was more frustrating as googling how to do something in Python, as a complete newbie, and then after fighting with what I have found, realizing that it is a Python 2 solution, and I choosed version 3, since that's what "elders" advised.

Anyway, PHP is alive and well, people picks it for new projects too, and 7 was a big jump forward in the right direction, imho... it is just slowly getting better. People also thought that C++, my second favorite language, is also destined for graveyard...and, it isn't. :-)

Achshar• 10 years ago

What's the first one?

vesak5• 10 years ago

I started my career with PHP, it really is a bummer that it seems destined for the language graveyard

I don't think you should worry about it. There are so many languages and organizations out there, majority of them better than PHP for nearly every task.

Just ignore PHP and be happy! I'm trying to get there currently, but just need some more time to shed the pain of being in a rather obstinate PHP organization for a few years :)

lucb1e4• 10 years 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.

dom03• 10 years 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?

lucb1e4• 10 years ago

If you can specify what exactly is unclear, I might be able to clarify something...

ComputerGuru• 10 years ago

He is referring to the allegations of sexual abuse against Tor developer Jacob Applebaum.

Jahak• 10 years ago

Coool

allan_s2• 10 years 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'.

aindhaden3• 10 years 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).

dom03• 10 years 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?).

markharris99• 10 years 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• 10 years 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• 10 years ago

Because in PHP, you can actually pinpoint dependencies on a specific version.

kyriakos2• 10 years ago

Your last sentence really doesn't leave much of a choice.

smcl• 10 years 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 :)

ceejay3• 10 years 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.

vesak5• 10 years 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.

No programmer can expect to use just a single language over their whole career. They might have career stability if they choose that but very risky stability.

vesak5• 10 years ago

No reason really to use PHP for a new project in 2016. Then again, no huge reasons not to use it, either. Sure, it's slightly sub-standard in many small ways, but your success or failure is probably not hanging on those things.

So if Go looks better to you, you should use that.

naranha5• 10 years ago

Yeah PHP can be pretty slow. For example on the symfony3 project (also with Vuejs) I currently work on which has ~6 doctrine DB classes, 5 controllers and returns just a simple json representation (1kb) of one the entities using symfony serializer I get response times of 70ms in production mode on an i7-4790K with 16 Gigs of ram. Getting the same entity simply from CouchDB yields response times of 3ms.

The problem is that PHP needs to bootstrap the entire environment for every request (minus some more or less efficient caching) which may be OK for monolithic applications but as soon as you want to build an app on HTTP2 that runs many requests, it will just always feel sluggish. And for this symfony already cheats massively by merging all class files into one huge bootstrap.php file etc. PHP just wasn't made for large applications.

fetbaffe6• 10 years ago

With Doctrine, you need to know what and when to enable caching in the correct layer. Complicated.

Personally I avoid ORMs and write SQL, better control and better performance.

ceejay3• 10 years ago

I agree there are very few people who know PHP well enough to build large web apps with it. On the same token I doubt, once you get that big to where it really matters, there are many web devs who know how to write web apps that scale well at all.

Everyone else is just taking advantage of a few milliseconds here and there (for example compiled language vs interpreted language) that might "appear" the language is better suited to the task, but ultimately only are as good as the architect(s) of the system made them.

I disagree PHP the language is deficient in any significant way that would prevent anyone from building large, modern web apps with it.

tyingq4• 10 years ago

PHP needs to bootstrap the entire environment

We have pretty good success just using a user space cache, like apcu or memcached, along with the bundled opcache.

It does still have some bootstrap overhead with each request, but it's not become a performance barrier.

I suppose this is different at a certain scale, but I'd wager that's a pretty small percentage of real world use.

fetbaffe6• 10 years ago

  - easy deploy 
  - large community
  - anyone can code PHP and become productive fast
  - No built in shared state. 
  - PHP is available almost everywhere
  - proven
  - simple development cycle

jstewartmobile• 10 years ago

As someone who uses both Go and PHP, I think they're separate use cases.

The up-side to PHP is that it is super-flexible. The down-side to PHP is that it is super-flexible. You can work fast with it, which also allows you to be extremely sloppy with it. The programmer has to wield all the discipline, because the language sure isn't going to help.

The up-side to Go is that Rob Pike is older, wiser, and learned all of the mistakes of C and C++. Rather than have it be all things to all people, he made some very opinionated design choices with crystal-clear trade-offs. More code will have to be written. It will be in an imperative style. Errors will need to be handled explicitly rather than through a catch-all exception. Elbow grease! Elbow-grease that results in more robust code that is easier to understand and reason about.

So, why PHP? Sometimes quick and workable is preferable to slow and great.

Lazare• 10 years ago

Golang isn't a bad option...but neither is (modern) PHP, Python, or Ruby. (Or .net, JVM, nodejs...) Each has some specific advantages, and that absolutely includes PHP.

PHP right now is in an interesting space: It's very stable, it has an enormous ecosystem, it has some extremely strong frameworks and tooling, the syntax has stopped being egregiously bad, it's starting to get quite fast, and the PHP request/response model is very attractive for some purposes, and avoids an entire class of bugs which crops up with, eg, nodejs.

If you're doing something where PHP is appropriate (which is a lot of stuff), and you're familiar with it, you're going to be extremely productive. Switching to golang (especially if not familiar with it) is like deciding that instead of going to the supermarket and buying a loaf of bread, you're going to buy a farm and figure out how to grow wheat. You have the ability to end up with a better product, but there's no promise you will, and it'll be a lot more work.

Apparently the client has some server side operations which are particular heavy and mentioned that php/python/ruby are just too slow

Of course if the client requires you to use golang, then sure, use golang. But it makes me wonder about the design the client is imagining. If your web server is trying to do very intensive calculations as part of the request/response cycle, you're probably doing something very, very wrong. But if you're not doing that, why does your need to do intensive calculation impact your choice of frontend? What's stopping them from having a lightweight frontend which queues up jobs in a task queue, and then have workers written in golang or C or whatever? And then maybe a websocket server to feed results back to the browser as they arrive? Where did they get the idea that a project needed a single language for every feature?

egeozcan4• 10 years 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.

kyriakos2• 10 years 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• 10 years ago

no template tags

Why? Native PHP excels at html templating, that's what it was created for.

scintill76• 10 years 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.

organsnyder• 10 years ago

With those things removed, what would be PHP's differentiating features? As I see it, it really has two things going for it:

1. Ease of quick-and-dirty prototyping

2. Large application code-base (especially Wordpress)

Your proposals would negate both of those selling points. What would be left to make it attractive? There are plenty of other languages that already meet your requirements.

aindhaden3• 10 years ago

I've previously toyed with the idea of a "cleaned up" PHP. And each time I abandon it when I remember that Perl, Python and Ruby already exist.

paulryanrogers• 10 years ago

And both Perl and Python suffer/benefit from radical breaks that split the ecosystem.

olemartinorg2• 10 years ago

I'm glad they don't go in the 'Python 3' direction, and as far as I've seen, the PHP core developers try very hard not to break too much of backwards compatibility at a time - which is a good thing.

Disclaimer: Actually a PHP developer. I know for a fact that if your proposal caught on, my managers would not like us to spend time rewriting a million lines of code to what is practically a new language. That doesn't contribute to making money for anyone.

egeozcan4• 10 years ago

Hey, I totally agree! That's why I said a new extension (not necessarily a language extension, maybe a file extension that switches to alternate parser like, hmm, ".phpx") and both ways compatible. Including the "new style" would be possible from "classic style" and vice versa.

fetbaffe6• 10 years ago

Dollar ($) as prefix to variable names is actually quite good. You know instinctively what is a user created variable and not a language keyword. Easy to find variables when scanning large chunks of code and easy to use with string replacement to avoid string concatenation or sprintf.

Opening tag at the beginning of file is not really worth of doing anything about. If you separate concerns in your code, you don't do HTML in your model code, therefore the only tag in a the vast majority of PHP files is the opening tag a the top of the file.

Paradoxically, today you don't use PHP as templating language in modern PHP, because it is clunky. You use a templating language like mustache or twig.

Standard library, yes. That ought to be fixed. My proposal to solve that is to implement function autoloading and support for callable types (parameter and return type signatures to callables). With that you could start implement outside of PHP core and start deprecating old core functions and supply a library shim for those who need it.

And also with those two language features, it will be much easier to do functional programming instead of the now dominating OOP i the PHP community.

PHP since 5.5 is quite good and with this release it is even better. It is flexible but at the same time rigid with very good performance. No built in state, which is perfect for stateless API:s.

egeozcan4• 10 years ago

You convinced me generally, I can't agree with this only:

Dollar ($) as prefix to variable names is actually quite good. You know instinctively what is a user created variable and not a language keyword. Easy to find variables when scanning large chunks of code and easy to use with string replacement to avoid string concatenation or sprintf.

Dollar prefix is hard to type with many keyboard layouts. You can also get the same effect with let/var/def/whatever and without the useless repetition. Also, any text editor with minimal support for your syntax would be able to highlight the definition/usages. The theoretical Utopian syntax would perhaps also allow $ in template strings. Further,

    $foo;

is a bit ambiguous because in a REPL, it would output foo, error if foo is not defined; in source code, it would define foo, no-op if already defined. While `def foo;` would only be valid if foo isn't defined and that'd be creating the variable. foo, by itself, would have a consistent meaning.

rpeden2• 10 years ago

To cover the cases where I want to use something a bit cleaner while still interacting with the PHP ecosystem, I've been using Haxe and compiling it to PHP. I've found that it works quite well; it compiles into nice, readable code. I actually don't mind PHP 7+, though. It's much more pleasant to work with than it used to be.

The bits of code that talk to native PHP functions will be platform specific, but I've been building up a little library of utilities that work with Haxe's other compilation targets - mainly JS, C++, Python, and C# for me. I've been especially impressed with its Javascript generation - it emits very readable and understandable JS, and its dead code elimination is quite smart; if you import a library and only use one method from one class, that's all you'll get in your compiled code.

egeozcan4• 10 years ago

After reading your comment, I gave Haxe another look. Actually, I don't remember why I didn't use it in the first place. I'll perhaps give it a go.

TazeTSchnitzel3• 10 years ago

Because then we'd have to maintain two languages rather than one.

mike503• 10 years ago

If you want something like that, why not just use a different language? Why should a language drop all of it's basic fundamental syntax? PHP should be PHP, not turn into VB/ASP.Net/ES6/Java whatever other syntax and notations and stuff people enjoy from other languages.

That's like having a son, growing up as a male, maturing, and then saying "I want you to also be a female now" - if you want a daughter, have another child.

gtbono• 10 years 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• 10 years 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• 10 years 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.

PHP 7.1.0 Released

Related Stories