Live data from Hacker News

Things you should know about PHP 7

pages.zend.com

31–40 of 124 posts

Re: Things you should know about PHP 7

#31
post #16

Seeing this: > function add( ... ): float {} I think a much better choice would have been: > float function add( ... ) {} Or just: > float add( ... ) {} Since that's how it's done in other languages and people would feel at home with it.

Haxe uses the first syntax, as does AS3. So it's not like "other languages" are universally opposed to this order.

Go also has a similar syntax (except the colon)

Re: Things you should know about PHP 7

#33
post #23

Heck, I'm kinda felling bad as a Pythonista. We're lagging badly speed wise. Sure, there's PyPy but it's not compatible with the mainstream C-Extensions so pretty much a no-go for most of my projects. Hopefully Piston will come to rescue in the future.

Well, maybe you should review your stack. Which C extensions are you missing? There are alternatives for the most part (barring GUI)

The ones I miss most frequently are a faster json parser (I use ujson), a faster msgpack parser and a faster database driver. The pure python versions (even on PyPy) don't make the cut :(

Re: Things you should know about PHP 7

#34
post #12

Earlier quoted context omitted.

Why?

The security implications and unpredictable resource availability never made it feasible to run a real production site from shared hosting.

What? You are suggesting that everyone should run their own server? And you are suggesting that nobody even ran a real production site on shared hosting?

You could say the exact same thing about VPS servers compared to dedicated hosting and be equally wrong. Please accept that there are different use cases that come with different solutions, of which shared hosting is one.

Re: Things you should know about PHP 7

#35
post #3

TL;DR: 1. Scheduled to come out in Q4 2015 2. operator, see https://wiki.php.net/rfc/combined-comparison-operator 3. Return Type Declarations & Scalar Type Hints 4. Speed improvements (25-70%) 5. Yep, speed improvements are for real. You're welcome.

Thank you. This website is completely useless on mobile.

It's also completely blank without javascript.

Re: Things you should know about PHP 7

#36
post #12

Earlier quoted context omitted.

Why?

The security implications and unpredictable resource availability never made it feasible to run a real production site from shared hosting.

Interesting perspective. I have clients who have been making very healthy mid to high six figure incomes off of their commerce sites, blogs, and CPA sites which live on shared hosting.

Good thing they didn't get your memo.

Re: Things you should know about PHP 7

#37
Being a PHP dev since the early 00's it's great to see the language moving forward with features and performance and seemingly less hate towards it from the developer community at large. For a while there seemed to be a "PHP-shaming" thing going around. If you did PHP you were sort of in an untouchable uncool class.

Re: Things you should know about PHP 7

#38
While I eagerly look forward to PHP7, you can get more than PHP7 speed now with HHVM, and HHVM has never been easier to use.

But competition is good, great actually. HHVM recently folded in JIT regex like PHP7, so they are copying from each other.

Re: Things you should know about PHP 7

#39

Earlier quoted context omitted.

Thank you. This website is completely useless on mobile.

It's also completely blank without javascript.

Why are you not running javascript? Is it a environment restriction, out of security concern or personal preference? Since tone can be tricky on the internet I'll just add that I am genuinely curious about this.

Re: Things you should know about PHP 7

#40
post #21

Seeing this: > function add( ... ): float {} I think a much better choice would have been: > float function add( ... ) {} Or just: > float add( ... ) {} Since that's how it's done in other languages and people would feel at home with it.

I thought that was rather odd as well. Are there many languages using this form of return type specifier?

It's fairly common in languages that determine (return) types themselves, e.g. Haskell, Scala and F# all use this syntax. Most languages that use a C-style syntax put (return) types in front.

It makes very little sense for PHP. A function definition now even has both styles:

`function foo(argtype arg) : rettype` instead of `function rettype foo(argtype arg)` or `function foo(arg : argtype) : rettype`.

Post reply on HN