Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming changes in PHP 7.1

dotdev.co

Post reply on HN
Print view View original

101–110 of 137 posts

Re: Upcoming changes in PHP 7.1

#101

Post by greatdipper »

ars wrote: post #95
greatdipper wrote: post #93

Earlier quoted context omitted.

Bashing Php should be encouraged just like bashing any other bad practice.. For example. Take the case of MySQL injection. People does not hand wave SQL injection vulnerabilities by saying. "Na, It haven't happened to me ever, even after 10 years of making websites using mysql". Just like that. Use of PHP IS a bad practice today.

The fact that you think SQL injections are actually MySQL injections tells me you are not qualified to criticize PHP. Get a few more years of experience then come back.

>SQL injections are actually MySQL injections

What? Where did I say so?

I said "people does not hand wave SQL injection vulnerabilities by saying they haven't encountered it in their 10 years of experience with MySQL".

That does not mean all sql injection vulnerabilities are limited to MySQL!

Is this one of those of tactics that are frequently employed by php apologists to derail arguments against the language?

Re: Upcoming changes in PHP 7.1

#102

Post by detaro »

peterbixa wrote: post #85
JonoBB wrote: post #83

Can we please change the link to the original article ( https://dotdev.co/upcoming-changes-in-php-7-1-76ebea53b820#.... ) "Learning Laravel" is a known plagiarist, who has a habit of ripping off content from other Laravel sites.

It's just a summary of the post. Are Facebook and other sites doing something wrong as well?

Submitting a facebook post about a different post instead of the post itself is against HN rules as well, yes.

Re: Upcoming changes in PHP 7.1

#103

Post by wtetzner »

arenaninja wrote: post #75
spdionis wrote: post #54

Earlier quoted context omitted.

Even if you have a point it wouldn't matter because making void functions return something else than null would be a big (useless) BC break. There's a lot of code that uses "return;" to mean "return null;" and honestly I don't see it as a big problem.

The point I was trying to make is that PHP does not have -- nor should it have, I think -- a concept of void. Functions without a return statement already return null. "return;" is already equivalent to "return null;" as well, as you pointed out. It would be more consistent to type-hint return null instead of introducing a new return type (void) into the language. I know PHPDoc already uses "@return void", and I have…

I think having a void return type makes a lot of sense, because it says "this function will never return anything but null".

Re: Upcoming changes in PHP 7.1

#104

Post by ars »

meritt wrote: post #100
ars wrote: post #96

Earlier quoted context omitted.

> has been shortened to [] and now lets you specify keys (disclaimer: I was involved in both of these Maybe you can answer this for me. Will this work: $f = [$c, $d] = [1, 2]; i.e. set $c and $d to 1 and 2, then return the array and store in $f.

It should because: $f = list($c, $d) = [1, 2]; does exactly as you describe and this is literally just a shorthand syntax for accessing list().

Thanks. What about:

  $c = 2;
  $d = 3;

  $f = [$c, $d] = [1, 2];
Is $f: 2, 3 or 1, 2? I assume 1, 2 because if not then it's both an array constructor and destructurer at the same time which would be interesting.

Plus:

  $f = $c = $d;
is 3;

Re: Upcoming changes in PHP 7.1

#105

Post by ars »

greatdipper wrote: post #101
ars wrote: post #95

Earlier quoted context omitted.

The fact that you think SQL injections are actually MySQL injections tells me you are not qualified to criticize PHP. Get a few more years of experience then come back.

>SQL injections are actually MySQL injections What? Where did I say so? I said "people does not hand wave SQL injection vulnerabilities by saying they haven't encountered it in their 10 years of experience with MySQL". That does not mean all sql injection vulnerabilities are limited to MySQL! Is this one of those of tactics that are frequently employed by php apologists to derail arguments against the language?

A: That isn't what you said. You said: "Take the case of MySQL injection."

Second, bringing up MySQL when talking about SQL injection is rather odd, and I don't see any reason you added that except that you don't realize MySQL is irrelevant.

> to derail arguments against the language?

Your "arguments" were very poor. There was no need to detail them.

Re: Upcoming changes in PHP 7.1

#106

Post by busterarm »

greatdipper wrote: post #92
busterarm wrote: post #79

Earlier quoted context omitted.

"Yeah, well, you know, that's just, like, your opinion, man." Seriously though, it's just a tool. Sometimes it's the right tool. I come from working with other dynamic languages to using (modern) PHP daily in my current job and it's fine. Absolutely fine to work with. Does it have gotchas? Sure, just as much as any other language.

>Sure, just as much as any other language. Did you see the thread I just linked? https://www.reddit.com/r/PHP/comments/41bm7j/new_rfc_allow_s... I don't see something like this happening this in any main stream language. That example illustrates one thing very clearly. How you believe you KNOW the language, and how it pulls the rug from under your feet in the most unexpected way. You can wait for it to happen to you.…

There's always some "here be dragons" area/library in any language. I've had it with Ruby, JavaScript, Clojure, Scheme and PHP.

It's really easy to pick on PHP's array methods. Sure there are problems there. What that means though is that when I'm using them I refer to the documentation frequently. I do this anyway, with any language.

The language never made or broke any promises to you, except where the specification is incorrect. Create a ticket when you find it. Notice how in the example you linked that the documentation is explicit about that caveat.

Programming languages are just tools. They are not your girlfriend. They are not your religion. There is no one tool to rule all tools and you're not entering into some major commitment in life to use them.

Re: Upcoming changes in PHP 7.1

#107

Post by djsumdog »

TazeTSchnitzel wrote: post #15

I'm more excited by some features not detailed in the article. Return type declarations, which were introduced in PHP 7.0, are being enhanced somewhat. First, it's now possible to declare nullable return types (previously all return types did not permit null): public function getFoo(): ?int; (You can also use ? on parameter and property types.) Second, we now have a void return type for functions where there is no us…

I'll be honest that I was firmly in the /r/lolphp camp for years, but PHP7 shows real promise. There's a real AST parser and the core team seems to be doing a lot to shore up the language.

I still think adding a string to a number should error instead of giving a warning, but one thing at a time. PHP7 and the future roadmap makes it look like PHP is on a path to not turning into Perl.

Re: Upcoming changes in PHP 7.1

#108

Post by conmarap »

I'm saying this in the nicest possible way: I hate PHP and hope the project dies tomorrow. And it's funny because I use it at my job everyday. I suppose that's why I've grown to loath it that much. I should say that it is great for some things and it is very easy to stage and cheap to maintain, but it is a language from the previous century that has massively failed to adapt to current programmatic trends and patterns. And I shouldn't even start on its API, which to this day seems like the equivalent of a two year old child's drawing. Laravel and Eloquent made things a bit better, but still... Man, this language is a hot mess.

Re: Upcoming changes in PHP 7.1

#109

Post by chatmasta »

Supporting http/2 SERVER_PUSH seems cool at first glance, but doesn't it significantly increase the attack service for RCE vulnerabilities, being that it accepts arbitrary content from remote servers and passes it into a callback function?

It looks like PHP implemented SERVER_PUSH [0] via libcurl [1], openly described as a "work in progress."

I'm sure all the code is "well written", both in PHP and libcurl, but I can't shake the feeling that we'll see at least one significant vulnerability as a result of this new feature. The two github issues on the feature, one referencing a segfault caused by a double-free [2], and one caused by server-specific protocol issues [3], do not help to assuage my worry.

[0] https://wiki.php.net/rfc/curl_http2_push

[1] https://daniel.haxx.se/blog/2015/06/03/server-push-to-curl/

[2] https://github.com/curl/curl/issues/529

[3] https://github.com/curl/curl/issues/530

Re: Upcoming changes in PHP 7.1

#110

Post by tomschlick »

naranha wrote: post #14
codeulike wrote: post #9

... Note the syntax isn’t the usual double pipe || operator that we associate with or, rather a single pipe | character ... ... PHP 7.1 introduces visibility modifiers to constants ... ... With PHP 7.1 it is now possible to specify that a function has a void return type, i.e. it performs an action but does not return anything ... ... Example four contains numeric values, so everything else is stripped out, and the su…

I wonder why PHP includes more and more type checks and visibility features, when all those checks are performed at runtime. What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification. I mean, I get that type checks are useful for IDEs, but enforcing these rules at runtime using fatal errors just does not make any sense to me.

> What good does it do when your code suddenly throws a fatal error at runtime because you did not respect the type specification.

The good it does is it stops your application from possibly continuing on with buggy code.

This is especially important in something like billing code. Imagine if your code was expecting an integer (bill amount) but got a string instead that via the types system evaluated to 0 or 1 instead of the real integer... In that case you might charge customers less or more than you should have and its a big deal trying to get all that fixed.

Better to just throw an error which you can see in an exception handling system like Sentry and take care of the problem.

Post reply on HN