Live data from Hacker News

Upcoming changes in PHP 7.1

dotdev.co

91–100 of 137 posts

Re: Upcoming changes in PHP 7.1

#91
post #14

... 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.

>I wonder why PHP includes more and more type checks and visibility features

Because they are easy to implement (function type hints, typed properties) and the php community have a collective, insatiable, perpetual hardon for features that are supposed to enhance correctness..

So the core devs are eager to propose these kinds of features. And the community is eager to accepts them without much thought..

To see how child like this mentality towards these type of features, see this comment, where a Php expert makes a big deal regarding when a user omitted mentioning the type of a value....

https://www.reddit.com/r/PHP/comments/4k2htl/ive_just_given_...

Re: Upcoming changes in PHP 7.1

#92

Don't use Php. Just don't. It is a stupid, stupid piece of crap. It is very hard, even for people with more than 10 years of experience, to know all the potential gotchas that are hidden deep inside this death trap of a language [1] You will be surprised how casual the actual core development of the language is. Tiny behaviours are added, modified and removed with little or no thought and with as little justification…

"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. Or you can learn from the experience of others.

Your pick.

Re: Upcoming changes in PHP 7.1

#93
post #78

Don't use Php. Just don't. It is a stupid, stupid piece of crap. It is very hard, even for people with more than 10 years of experience, to know all the potential gotchas that are hidden deep inside this death trap of a language [1] You will be surprised how casual the actual core development of the language is. Tiny behaviours are added, modified and removed with little or no thought and with as little justification…

PHP community is huge and you are generalizing things from your limited experience. The language is not perfect (is any?) but it works and delivers business value. If it's not your cup of tee, that is fine, but I don't see you promoting better solutions, just bashing on PHP. Some people think that that is cool, well, it's not.

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.

Re: Upcoming changes in PHP 7.1

#94
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.

Don't you see the read more link? The author is listed there, too. Don't ignore all the things.

I know you're trying to be clever, but seriously, please stop. He is a KNOWN plagiarist. All of his articles are copy-pasted from elsewhere (even if he does sometimes credit others in his posts).

He has even stolen content from other Laravel books and published it as his own book.

Re: Upcoming changes in PHP 7.1

#95
post #78

Earlier quoted context omitted.

PHP community is huge and you are generalizing things from your limited experience. The language is not perfect (is any?) but it works and delivers business value. If it's not your cup of tee, that is fine, but I don't see you promoting better solutions, just bashing on PHP. Some people think that that is cool, well, it's not.

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.

Re: Upcoming changes in PHP 7.1

#96

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…

> 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.

Re: Upcoming changes in PHP 7.1

#97
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.

I don't get why they do it. Leave the fact that is unthetical, it's just annoying for users who can't read the whole post and at the same time very unproductive from a SEO perspective

Re: Upcoming changes in PHP 7.1

#98

Earlier quoted context omitted.

PHP does have the shorthand ternary operator `?:`, though, which does what you want here: $ php -r 'var_dump(0 || 42);' bool(true) $ php -r 'var_dump(0 ?: 42);' int(42)

Wow. OK, I am a big user of the ternary operator, but I hadn't come across omission of the middle part until now. To be honest, it's not the most accessible syntax (especially if you're coming from another language), but at least I have the option now - thanks! edit: Just to clarify for anyone else unfamiliar with it: $ php -r 'var_dump(42 ?: 0);' int(42)

Depending on how far back you have to support (e.g., WordPress is still supporting 5.2), omission of the middle part wasn't supported until PHP 5.3.

Re: Upcoming changes in PHP 7.1

#100
post #96

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…

> 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().
Post reply on HN