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

131–140 of 197 posts

Re: PHP 8.5

#131

Post by idoubtit »

gramakri2 wrote: post #30
darkamaul wrote: post #26

PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow. I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for…

IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.

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/closures_in_const_expr

Re: PHP 8.5

#132

Post by matula »

inovica wrote: post #28

I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since t…

I've seen a few other comments also talk about PHP becoming more complex. However, I have "simple" code built using 5.3 and it works perfectly fine in 8. So I guess it CAN be complex, but doesn't really need to be. The biggest changes I would make to that code are fixing the multiple 'switch' and 'if/else' blocks to an anonymous function or some mapping... but it's not required.

Re: PHP 8.5

#133

Post by danaris »

darkamaul wrote: post #26

PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow. I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for…

I dunno; I started with PHP 5 (actually, I think I started in late PHP 4), and I've only been happy with the changes as it's evolved.

The only one that's caused me any significant stress is the deprecation of the old `mysql` DB interface; I had to refactor a whole bunch of code for that, since I'm maintaining a codebase that's been in continuous use & development since 2001.

The additions to PHP since 5 add more things you can do, but they don't really change the simple things you can do to first learn PHP. You can still just create a .php file and start interspersing HTML and <?php script tags with basic operations.

Re: PHP 8.5

#134

Post by danaris »

phplovesong wrote: post #74
deaddodo wrote: post #56

Earlier quoted context omitted.

It has nothing to do with being “too hard”, and everything to do with not making sense to the type system. PHP is weakly-typed and heavily reflection-based (so everything is aware of it’s and each other’s type at all times). Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strong…

> And would be a massive headache to implement Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen. > Adding generics to PHP would make CS fundamentalists somewhat happy PHP has really only one collection datatype (the infamous array), so hav…

> you cant return an typed array from a function, witch is just really bad.

Why is it bad?

In particular, why is it worse than not being able to declare a typed array in your current scope? (I understand the basic argument in favor of typed arrays, but I also understand why PHP would choose not to go that route; I'm not sure I see how it's worse to not be able to return one from a function, given that they don't exist elsewhere.)

Re: PHP 8.5

#135

Post by okeuro49 »

tim333 wrote: post #127
segmondy wrote: post #113

Earlier quoted context omitted.

It's a real problem with almost all software today, nothing ever gets done. they just keep piling unto it no matter how great it was. the idea of simplicity as a goal and feature is lost on this generation.

Simplicity may often get ignored but I think it's been a big reason for Python's success which has gone from about #10 on the TIOBE language list to #1 since when I started learning it, which was probably around when the XKCD "everything is so simple" cartoon came out. ( https://xkcd.com/353/ )

Doubtful it is anything to do with simplicity.

Python's success is explained by it being the language of choice for AI.

Re: PHP 8.5

#136

Post by TimWolla »

idoubtit wrote: post #131
gramakri2 wrote: post #30

Earlier quoted context omitted.

IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.

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

> As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#"

Yes, unfortunately the off-the-shelf software of the Wiki uses a custom-built highlighter instead of the `highlight_string()` function that is bundled with PHP: https://www.php.net/manual/en/function.highlight-string.php

Re: PHP 8.5

#137

Post by pjmlp »

deaddodo wrote: post #117
pjmlp wrote: post #114

Earlier quoted context omitted.

A pub quizz would consider more than GCC and MSVC, and still I would bet many would fail if talking only about those two. And I would double down on my bet regarding ISO C related questions, as I have met a few folks that contrary to myself as language nerd, hardly know what is written there or have even opened the PDF drafts at least once in their life.

[flagged]

It definitely is, because we are discussing knowledge of programming languages specification across their whole lifetime.

Re: PHP 8.5

#138

Post by phplovesong »

duckerude wrote: post #120
phplovesong wrote: post #74

Earlier quoted context omitted.

> And would be a massive headache to implement Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen. > Adding generics to PHP would make CS fundamentalists somewhat happy PHP has really only one collection datatype (the infamous array), so hav…

Python managed to do this by not actually checking the types at runtime. If you declare a list[int] return type but you return a list[string] then nothing happens, you're expected to prevent that by running an offline typechecker. PHP chose to check types at runtime. To check that a value is really an array the runtime could have to loop through the entire array. All the types PHP currently implements are simple and…

Precisely. PHP has tools for this too, but lack the syntax. Right now you need to to all typings in comments, and thats just as bad as jsdoc was in 2005.

This could be the way PHP could go, they just need the lexer to handle types, and not do any runtime checking at all.

But i guess that goes against what the php devs want, but it sounds so wasteful, to typecheck the same code time after time even if it passed some sort of initial "compile time step".

Re: PHP 8.5

#139

Post by phplovesong »

danaris wrote: post #134
phplovesong wrote: post #74

Earlier quoted context omitted.

> And would be a massive headache to implement Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen. > Adding generics to PHP would make CS fundamentalists somewhat happy PHP has really only one collection datatype (the infamous array), so hav…

> you cant return an typed array from a function, witch is just really bad. Why is it bad? In particular, why is it worse than not being able to declare a typed array in your current scope? (I understand the basic argument in favor of typed arrays, but I also understand why PHP would choose not to go that route; I'm not sure I see how it's worse to not be able to return one from a function, given that they don't exis…

I often return some collection of types in an array eg [User, Config]. Right now my return type is just "array". To get this to work i need to build yet another wrapper class and all that, and thats just wasteful and totally unnecessary.

A even more simpler example is An array of some sort of Item. I cant return array(Item), but i only can return an array.

Re: PHP 8.5

#140

Post by idoubtit »

Adding new functions and alternative syntax has a long-term cost for PHP and the projects that use the language. I don't see much value in the new features of PHP5 announced on https://www.php.net/releases/8.5/en.php

- URI extension: there was already the internal `parse_url()` which was imperfect, and alternative libraries that were RFC 3986 compliant. An official extension will bring speed, but now there will be 2 official ways to parse URLs.

- The pipe operator is a matter of taste. In the release notes, the new code is more verbose, because it defines anonymous functions. This alternative syntax means keeping a consistent code style will be harder.

- The update of "clone" replaces 2 lines of code in some cases. Unless I misunderstood, it's a very minor change.

- The #Discard/void will replace the similar feature from static analyzers.

- Closures in constants is one of the 2 features that bring more than an alternative syntax. It's one more little step toward a preprocessor. But I'm not thrilled about the future #attributes assigned with complex closures.

- cURL persistent handles are a real performance feature, because curl_init() is costly.

- array_first() is a minor syntax-sugar. In a project of 100k+ lines of PHP, I probably could use it twice or thrice. Was it worth a global function?

Post reply on HN