Live data from Hacker News

Upcoming changes in PHP 7.1

dotdev.co

111–120 of 137 posts

Re: Upcoming changes in PHP 7.1

#111

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…

>It is a stupid, stupid piece of crap.

You haven't convinced anyone for either your eloquence or your argumentative skills.

All your comments in this post, furthermore, suggest a teenager or close. Not to be ageist, but "stupid piece of crap", "shittier community", "drama loving, infantile minds" show neither deep thinking on the subject nor much maturity.

Re: Upcoming changes in PHP 7.1

#112

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.

What do you think of the Perl 6 approach of providing both DWIM (weaker) and DWIS (stronger) typing?

* Numeric and string operators are kept distinct. For example `+` means numeric addition, never concatenation or some other string operation. To compare two strings, use `eq`, to compare two numbers use `==`. Etc. This sets things up nicely for supporting both DWIM and DWIS typing.

* DWIM typing: If you write something like `a + b`, you always get numeric addition. If need be the compiler tries to coerce `a` and `b` to numbers. `"12"` or `" 12" will both successfully coerce to 12. `"123foo"` and `"bar456"` will fail to coerce. If the coercion fails the program crashes at run-time.

* DWIS typing: To tighten type checking, add a type constraint. For example, `my Numeric (\a, \b) = ...` ensures that `a` and `b` only ever contain a numeric value.

Re: Upcoming changes in PHP 7.1

#113
post #104
post #100

Earlier quoted context omitted.

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;

Let's break this up a bit, remembering that assignment is right-associative:

  $c = 2; # Assign 2 to $c
  $d = 3; # Assign 3 to $d

  [$c, $d] = [1, 2]; # Assign 1 to $c, assign 2 to $d

  $f = [$c, $d]; # Assign [1, 2] to $f

Re: Upcoming changes in PHP 7.1

#114

Earlier quoted context omitted.

I was talking more about the inconsistency between return type void when it returns null. I'm asking whether this behavior has changed and functions without a return will now return void or ???. It's a pretty big inconsistency IMHO.

This is the same as other languages. In for example Java you have `public void method()`, and you then `return` which results in a `null`

This is completely incorrect. Java's null value is only valid as a value of an object type (e.g, Object x = null), and void functions don't return an object.

Re: Upcoming changes in PHP 7.1

#115
post #6
post #2

This is just an excerpt from https://dotdev.co/upcoming-changes-in-php-7-1-76ebea53b820#....

My favorite feature is definitely the square bracket destructuring syntax. This is great for bringing tuple-esque operations to the language.

i dunno, i found that kind of special functions which are actually language constructs like list(), isset(), etc always ugly. Ok, some more syntax sugar to let these things not look like normal functions is of course an improvement, but i wish they would do some more radical changes to the language. Why not add multiple return values like in golang to achieve that syntax? Isn't exactly that list() should emulate in some way? Than deprecate that list() crap and throw it away in 7.2. But instead they will keep that list "function" forever along that new bracket syntax because they are afraid some code from the 90s would break. On the other hand they don't stop adding minor complete irrelevant changes that break existing code from yesterday.

Re: Upcoming changes in PHP 7.1

#116
post #23

> Catching multiple exception types > Support class constant visibility Reminds me of what Rob Pike once said, "[Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more] are converging into a single huge language".

PHP should actually renamed to Javascript, but there is already that weird Lisp like scripting language claiming that name. If u ask me, there is somethin wrong in our matrix...

Re: Upcoming changes in PHP 7.1

#117

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…

> It is a stupid, stupid piece of crap. You haven't convinced anyone for either your eloquence or your argumentative skills. All your comments in this post, furthermore, suggest a teenager or close. Not to be ageist, but "stupid piece of crap", "shittier community", "drama loving, infantile minds" show neither deep thinking on the subject nor much maturity.

>you haven't convinced anyone for either your eloquence or your argumentative skills.

Even in this thread,

https://www.reddit.com/r/PHP/comments/41bm7j/new_rfc_allow_s...

even when the language shows its true color in front of their very own eyes, people continue to be in denial. (See arguments of /u/betterphpguy).

I don't bother to polish my arguments regarding this, because I know how futile it really is. A programmer who "likes" or Php cannot be convinced otherwise by arguments. If he/she is lucky, their own experience with the language and outside of it, will take them to that realisation.

I do this only for the benefit of any newcomer who might come across these thread, and might think that Php is on par with the other languages.

Re: Upcoming changes in PHP 7.1

#118

Earlier quoted context omitted.

I don't like PHP either, but that doesn't mean kneejerk reactions are excusable, and at the least on the first point you are wrong. Using | instead of || is not an inconsistency, but actually quite consistent. || is a short-cutting or comparison operator which returns the first true thing it encounters. | is a bitwise or combinator, which takes two sets of flags, and combines them into one set of flags that has all f…

> || is a short-cutting or comparison operator which returns the first true thing it encounters. I wish . The fact that it actually doesn't is one of the things that really bugs me about PHP: The above example will output: bool(true)

Actually || is short circuiting and behaves exactly as he described, it returns the first true thing it encounters.

  $ php -a
  Interactive shell
  
  php > echo 1 || die('die');
  1
This echo's 1, it doesn't die.

Re: Upcoming changes in PHP 7.1

#119

Earlier quoted context omitted.

> || is a short-cutting or comparison operator which returns the first true thing it encounters. I wish . The fact that it actually doesn't is one of the things that really bugs me about PHP: The above example will output: bool(true)

... ok, i gotta admit i had my Perl hat on for that reply.

You were actually correct -- see my above reply.

Re: Upcoming changes in PHP 7.1

#120

Earlier quoted context omitted.

> It is a stupid, stupid piece of crap. You haven't convinced anyone for either your eloquence or your argumentative skills. All your comments in this post, furthermore, suggest a teenager or close. Not to be ageist, but "stupid piece of crap", "shittier community", "drama loving, infantile minds" show neither deep thinking on the subject nor much maturity.

>you haven't convinced anyone for either your eloquence or your argumentative skills. Even in this thread, https://www.reddit.com/r/PHP/comments/41bm7j/new_rfc_allow_s... even when the language shows its true color in front of their very own eyes, people continue to be in denial. (See arguments of /u/betterphpguy). I don't bother to polish my arguments regarding this, because I know how futile it really is. A program…

Part of growing up is not caring for BS like this, because you can find this, and even worse caveats in any popular language (and worse stuff in non populars).

You will also realize that such caveats never prevented people from creating billion dollar companies with PHP (or C++, or JS, etc), and perfectly workable code, powering 40% of the internet.

The rest are child games.

Post reply on HN