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

PHP 8.5

stitcher.io

Post reply on HN
Print view View original

181–190 of 197 posts

Re: PHP 8.5

#181

Post by danaris »

phplovesong wrote: post #167
danaris wrote: post #146

Earlier quoted context omitted.

What do you mean, "to get this to work"? It's a PHP array. It will return whatever you need it to. What is not working?

The parts thats not working is if i return a plain "array" i can then put whatever inside it. Its basically the same as "any" but wrapped inside an array.

Sure.

But that is no different than if you created the array in that scope.

So, again: Why is it "really bad" that you can't return a typed array from a function? What is worse about that than not being able to create a typed array in the current scope?

Also: What, exactly, about that is "not working"? As I said above, I understand the basic arguments about typed arrays; they're conceptually equivalent to weak/dynamic types. And there is value in having strong and static types. But it's hardly a showstopper not to, and PHP works just fine even if you don't use any. It just...makes it easier for us, as programmers, to make mistakes.

So to say it's "not working" simply because it's possible to add elements to the array that don't match the types you want seems like an exaggeration.

Re: PHP 8.5

#182

Post by array_key_first »

phplovesong wrote: post #174
array_key_first wrote: post #142

Earlier quoted context omitted.

PHP typing is most definitely stronger than python overall. Yes array is the evil collection type of everything, but that's how it's meant to work. Array is the quick and dirty 'throw everything in there' thing. PHP has classes and they're very full featured and offer lots of type safety - use those.

> PHP typing is most definitely stronger than python overall. LOL, no its not. PHP has an weak type system, while python is strong. Both are dynamic. $sum = 10 + "50"; // 60 in PHP sum = 10 + "50" // TypeError in python

I mean from a static analysis perspective - type annotations in PHP actually do stuff, and you can type annotate pretty much everything. And people actually do it.

Also, you can just flip on strict typing in PHP, and you should know that.

Re: PHP 8.5

#183

Post by tguvot »

dotancohen wrote: post #177
tguvot wrote: post #145

Earlier quoted context omitted.

i still have phtml and php3 files somewhere in backups. used to run on php one of biggish local sites that you probably know

Starts with the letter R? PHP of that era, completely procedural with concatenated SQL, such fond memories.

not with R. with P

Re: PHP 8.5

#184

Post by rafark »

TimWolla wrote: post #136
idoubtit wrote: post #131

Earlier quoted context omitted.

Are the new features really readable? I have no idea what this code from the OP is meant for: #[SkipDiscovery(static function (Container $container): bool { return ! $container->get(Application::class) instanceof ConsoleApplication; })] final class BlogPostEventHandlers { /* … */ } As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#". See https://wiki.php.net/rfc/c…

The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples. Given that the cat effectively is out of the bag, does the example on the release page (sneak preview) make more sense to you: https://www.php.net/releases/8.5/en.php#closures-in-const-ex... ? >…

> The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.

Clout.

Re: PHP 8.5

#185

Post by rafark »

mg wrote: post #20

When I look at the new pipe syntax ... $output = $input |> trim(...) |> (fn (string $string) => str_replace(' ', '-', $string)) |> (fn (string $string) => str_replace(['.', '/', '…'], '', $string)) |> strtolower(...); ... I think why not just something like the following? $output = $input |> trim($) |> str_replace(' ', '-', $) |> str_replace(['.', '/', '…'], '', $) |> strtolower($);

Your second option was rejected years ago I believe. The pipes were designed to work alongside this rfc that was supposed to be in this new version (8.5) but due to time constraints it had to be delayed and it’s currently being voted https://wiki.php.net/rfc/partial_function_application_v2

Re: PHP 8.5

#186

Post by jasomill »

rini17 wrote: post #151
deaddodo wrote: post #111

Earlier quoted context omitted.

It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're talking about specification deltas, not the entire corpus. But, if you want an answer to your question: You can learn to avoid undefined behavior in about 30 seconds . If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an…

Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized. > You can learn to avoid undefined behavior in about 30 seconds. Source? I mean, if it's really that simple then som…

Before you could assume...null pointer derefs will be trapped by the OS

Before when?

  Microsoft(R) MS-DOS(R) Version 6.22
               (C)Copyright Microsoft Corp 1981-1994.
  
  C:\TMP>type foo.c
  void main() {
      long q = 0;
      q = 0/q;
  }
  
  C:\TMP>cl /Od foo.c
  Microsoft (R) Optimizing Compiler Version 5.10
  Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved.
  
  [...]
  
  C:\TMP>foo

  run-time error R6003
  - integer divide by 0
  
  C:\TMP>type bar.c
  void main() {
      long far *p = 0;
      long q = 0;
      *p = 0;
      q = 0/q;
  }
  
  C:\TMP>cl /Od bar.c

  [...]

  C:\TMP>bar
(system hangs)

Re: PHP 8.5

#187

Post by rafark »

dgb23 wrote: post #83
dotancohen wrote: post #10

Earlier quoted context omitted.

I downvoted you before reading the fine article. I'm back to correct that. The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unar…

Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features. Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts…

>Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.

The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is consider as the future scope of this rfc which is still being worked on: https://wiki.php.net/rfc/pattern-matching

Also, a lot of these half baked features are designed to be implemented in steps because of what I said in my other paragraph and to increase the odds of being accepted (it’s well known that it’s hard to get an rfc accepted and a lot of good ones haven’t been able to pass the voting phase).

When you consider this, it’s amazing that we get so much from so little.

Re: PHP 8.5

#188

Post by rafark »

hu3 wrote: post #150
xonre wrote: post #62

PHP should do a real major compatibility break and remove $ sigil from variable names. It's gonna be worth the pain!

I would love that. But yeah, it would probably kill PHP because it would break all code. Maybe https://getrector.com could auto-fix 99% of code but it would still be very hard to get adoption.

Would it though? I’ve been thinking about this for a while.

What about introducing a new file extension for this? Something like MyClass.p so that .php is for classic syntax and .p Can support newer syntax? You could support old codebases while at the same time support better syntax.

It’s probably too much for the core php team to maintain both though

Re: PHP 8.5

#189

Post by misiek08 »

nake89 wrote: post #6
calpaterson wrote: post #5

A lot of people are too proud to be associated with PHP. I am ready to admit that know nothing about the language except that a lot of people make cool things with it. My favourite PHP product at the moment is BookStack ( https://www.bookstackapp.com/ ), a really good wiki. I run an instance for my family and it's great. But there are loads of things. And I notice that many of the sites I like using...are built on we…

> A lot of people are too proud to be associated with PHP. How so?

A lot of mediocre devs sitting at corporations that migrated from PHP to Java and currently can’t write relatively good code in any language make jokes of PHP, because it was popular for some time. They won’t admit the language gave them food, they have no idea how language looks today and are way too proud to admit any of that.

Re: PHP 8.5

#190

Post by tuqqu »

array_key_first wrote: post #182
phplovesong wrote: post #174

Earlier quoted context omitted.

> PHP typing is most definitely stronger than python overall. LOL, no its not. PHP has an weak type system, while python is strong. Both are dynamic. $sum = 10 + "50"; // 60 in PHP sum = 10 + "50" // TypeError in python

I mean from a static analysis perspective - type annotations in PHP actually do stuff, and you can type annotate pretty much everything. And people actually do it. Also, you can just flip on strict typing in PHP, and you should know that.

Strict types determine whether a function accepts a variable of a certain type, casts it, or throws a TypeError. It does not affect int + string operations or anything else really
Post reply on HN