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

PHP 8.4

php.net

Post reply on HN
Print view View original

271–280 of 337 posts

Re: PHP 8.4

#271

Post by 9dev »

shikck200 wrote: post #266

Looks like PHP is going even further towards Java. I really loath getters/setters with passion. I really wish PHP instead focused on getting some sort of concurrency builtin and proper unicode string literals. That should be the main focus, instead of copying various features from Java.

Look at it this way: getters/setters are the only conceivable way Laravel could ever get something like static analysability, and I wouldn’t call that framework particularly Javaian. What they do is make a whole sleuth of magic code actually discoverable and understandable, but you’ll never have to use them if you don’t want to. And even if a library under the hood implements a getter, all you’ll see of that is $foo->bar. There really have been both more invasive and more Java-style features in the past than this one.

Re: PHP 8.4

#272

Post by Implicated »

shikck200 wrote: post #267
mg wrote: post #6

These days, I am super torn about what language to use for new web projects. PHP: - Easy to deploy: Upload files, done. - Easy to develop: Reload page, see changes. - Lots of HTTP tooling built in. - Fast. Python: - Great language. - Great code reuse system: Modules. - Nice framework: Django. - Less breaking changes in recent years.

Does anyone really FTP files like its 2003? Even in PHP you deploy with some sort of tool, like docker etc. The reload page thing is pretty much solved in all languages with a watcher. entr is a universal one, thats written in C and fast as anything. The thing (most) other languages have is unicode support and concurrency. In PHP there is basically none of these. Fast? You mean fast as in CPU bound tasks? 99.99% of P…

Sir, PHP can fly.

- https://www.php.net/manual/en/book.ffi.php

While I'm at it:

- https://pecl.php.net/package/tensor

- https://rubixml.com/

- https://github.com/RubixML/Tensor

Re: PHP 8.4

#273

Post by 9dev »

ChrisMarshallNY wrote: post #106
inerte wrote: post #105

Earlier quoted context omitted.

> With predictable results. People building and creating awesome new things? Increase in happiness and empowerment? More efficient processes and increase in productivity? New businesses being born? Wealth and value being added to society?

> More efficient processes and increase in productivity I'd have to see the numbers on those ones. But I am not a "gatekeeper" type, maybe you are confusing me for one. I'm a high school dropout with a GED, and have been staring up people's noses, all my life. I just believe that any job we do, should be a good job. Build on a sand foundation, and you'd better not go too high, or Bad Things Happen.

I agree that it’s especially sad then to see someone with your background taking that position then. While we’re busy discussing inelegant abstraction patterns in code, a bunch of founders have written the foundations of a successful startup with horrible code, creating work for better programmers (but worse founders) in the process.

A good friend of mine has founded such a company, and boy, I loathe his code. But at the end of the day, he’s incredibly good at getting something out of the door now, which is working. A language that makes this possible, while still scaling to fully type-safe and optimized bytecode with a JIT compiler if needed is a good one.

Re: PHP 8.4

#274

Post by 9dev »

LeftHandPath wrote: post #205

I went to look at array accessor overloading today and saw “Property Hooks” in the sidebar (under “Classes and Objects”). I didn’t know what they were, so I clicked. I was bewildered that I had never run into them before, used them in my own code, or seen them used by others. Come to find out they’ve only been around for about a day! Reminds me of some of the lovely expressibility and syntactic sugar that’s pulled me…

The next thing I would love to see adapted would by Python—style array access:

  $foo[1:-3:2]
Instead of the usual array functions, which could stick around for BC. That would be amazing

Re: PHP 8.4

#275

Post by 9dev »

nneonneo wrote: post #59
chx wrote: post #53

Earlier quoted context omitted.

That would be some really old library. Already in 2012 when Composer was released there was PSR-0 and today almost all libraries are Composer managed and using a namespace following PSR-4 which itself is ten years old. A library that old would almost surely not run on PHP 8 unchanged anyways. Surrendering the global namespace to the language is not so bad an idea.

Suppose I want to add some new code to an old website? Or I want to gradually upgrade an ancient code base - twelve years is not so old for PHP, when ancient frameworks like Wordpress are still alive and kicking.

Then you use your IDEs refactoring feature to rename your version of the function, or put it into a namespace, and you’re done in about 12 seconds.

Re: PHP 8.4

#276

Post by Spivak »

bwoebi wrote: post #237
wvenable wrote: post #235

Earlier quoted context omitted.

There are many times I would love to have an automatic backing field in C#. C# will do that if you use the default setter but in cases where that's not possible I dislike having to both declare a separate field and having it available to the rest of the class outside of the setter.

C# 13 has this via the field keyword (as preview feature): https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... It's pretty similar to what PHP provides here, except that PHP uses "$this->propname =" and C# uses "field =". Edit: As someone involved in the RFC, it's somewhat funny, because we considered a special variable like "$field" or "$value" too magic, and C# does just that with a field keyword.

I think it being a keyword does change how magic the feature feels. "$field" and "$this->name" make me think that this behavior is playing by the normal rules of the language but is implemented using some trickery to edit the local scope of this function to add or modify variables. When it's a keyword it says this is a special form and that this is a feature of the language itself.

Re: PHP 8.4

#277

Post by shikck200 »

Implicated wrote: post #272
shikck200 wrote: post #267

Earlier quoted context omitted.

Does anyone really FTP files like its 2003? Even in PHP you deploy with some sort of tool, like docker etc. The reload page thing is pretty much solved in all languages with a watcher. entr is a universal one, thats written in C and fast as anything. The thing (most) other languages have is unicode support and concurrency. In PHP there is basically none of these. Fast? You mean fast as in CPU bound tasks? 99.99% of P…

Sir, PHP can fly. - https://www.php.net/manual/en/book.ffi.php While I'm at it: - https://pecl.php.net/package/tensor - https://rubixml.com/ - https://github.com/RubixML/Tensor

Seems like that requires some sort of ad-hoc PHP extension. These are not in the standard PHP distribution? I would not want to rely on some random PHP extension that maintained by a single guy for anything production grade. Compare that to something like tensorflow thats backed by a HUGE community of maintainers.

Re: PHP 8.4

#278

Post by 9dev »

handzhiev wrote: post #166
jayflux wrote: post #51

Earlier quoted context omitted.

> Easy to deploy: Upload files, done I know people love to say this, but does anyone realistically make websites or web apps that way? No, not really. Even with PHP there are frameworks, there is a package manager, there is version control, and there are deployment systems. Pretending that PHP developers are uploading a .php file to a shared hosting server (like in 2002) to suit the narrative feels disingenuous to me…

I do it all the time, thank you very much. For a simple web app I don't even need a framework - you can literally create a simple files/folder structure, include files, include folders and get stuff done. An yeah, you can also upload the files by FTP. For something more complicated I'd use WP or Code Igniter depending on the specific project. And then you can again just SFTP those files to the server.

That only works if your application has reasonably few users. Otherwise, your upload will result in some requests hitting a partially completed code base overwrite, that is, only some of your changes have been uploaded at request time, possibly leading to an error. This is a nice strategy for a hobby project, but it plain does not work for a business.

Re: PHP 8.4

#279

Post by hks0 »

wvenable wrote: post #168
mgkimsal wrote: post #162

Earlier quoted context omitted.

can't do that if you declare the properties on the class. __get only works for undefined properties.

Well don't do that then. :)

That advice doesn't always work in real life; otherwise for every compiler or linter check in any language, we could drop all those checks and tell the programmers not to do that.

E.g. if a base class declares a variable it can potentially break its children. Whose at fault here?

I agree with your original comment though. And if the bypass of exisitng fields is badly wanted, somehow marking __get to disregard them makes more sense to me.

Re: PHP 8.4

#280

Post by shikck200 »

9dev wrote: post #271
shikck200 wrote: post #266

Looks like PHP is going even further towards Java. I really loath getters/setters with passion. I really wish PHP instead focused on getting some sort of concurrency builtin and proper unicode string literals. That should be the main focus, instead of copying various features from Java.

Look at it this way: getters/setters are the only conceivable way Laravel could ever get something like static analysability, and I wouldn’t call that framework particularly Javaian. What they do is make a whole sleuth of magic code actually discoverable and understandable, but you’ll never have to use them if you don’t want to. And even if a library under the hood implements a getter, all you’ll see of that is $foo-…

I really dont want to access a property and have it do any sort of magic behind the scenes. This is just bad. Now a property lookup could do some IO, or even throw an exception. PHP should not aim to please the framework of the month, but it in fact seems like Laravel lobbied this into PHP core.

> but you’ll never have to use them

But i do. I now cant tell if im accessing a property or a getter. With custom functions (like getFoo()) it was annoying, but still obvious, now its just magic and library authors will 100% start to abuse this feature allover.

Post reply on HN