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

PHP 8.1.0

php.net

Post reply on HN
Print view View original

111–120 of 286 posts

Re: PHP 8.1.0

#111

Post by lolinder »

chubot wrote: post #93
the_gipsy wrote: post #74

Earlier quoted context omitted.

With a proper type system you don’t need to run your code 50 times a minute.

Code that passes type checks can also fail to solve the user's problem, make 10,000 database calls, or render a page that is completely unreadable. The human in the loop is a good thing. All things being equal, the type system is also a good thing, but what usually happens is that you end up checking your page once a minute or once every 10 minutes, not 50 times in a minute. That difference can make or break a projec…

It depends a lot on what you're working on. If you are building a front end with PHP as your templating language, then yes, the ability to instantly see your changes is huge. In my experience, when working on back end, the difference isn't that significant because you really want to be using unit tests anyway, not constantly interacting with the front end to test your work. In those back end cases, having a strong type system makes a huge difference.

I'm working on a project that has a legacy PHP code base and a new JVM code base. What kind of naturally happened is that we end up doing most of our front end work in PHP and all of our new backend work on the JVM.

Re: PHP 8.1.0

#112

Post by pdenton »

TazeTSchnitzel wrote: post #95
pdenton wrote: post #49

Question: does class_exists still return TRUE when given the QCN to an enum? Because it's not possible to instantiate an enum, if one appears in the constructor of a class it'll break auto-wiring. I've written my own IoC containers and one fundamental assumption in them is that when class_exists returns true, it is what it says on the tin. Using a specialized factory would still be possible. I wonder if other contain…

There's already kinds of classes that can't be instantiated, why would this specifically be a breaking change?

If by "kinds" you mean abstract classes, yeah. I just checked, there's no special handling for those since requesting them from the container makes no sense. I suppose a constructor could depend on an abstract type and expect an actual implementation, though. I haven't thought about that use case actually, but it's possible to configure a substitute for this case. Other IoC containers may handle this one better, since you may want to have different implementations depending on the current scope.

If you mean classes with private constructors, those are technically illegal. According to the PHP manual, constructors must be declared public. The fact that private constructors work at all should be considered an implementation detail.

Breakage occurs when something is said to be a class, yet isn't a class but still appears in the parameter list of a constructor. The container would instantiate a ReflectionClass of whatever is being requested and pass that around. At some point it'll call newInstanceArgs either with configuration-provided arguments or with auto-wired dependencies. The first case could still work, but foregoes auto-wiring.

Re: PHP 8.1.0

#113

Post by javier123454321 »

rbanffy wrote: post #77

Genuinely curious: who here thinks PHP is a good choice for a new project and also has experience with other languages such as Scala, Kotlin, Python, or JavaScript and their respective web frameworks?

Honestly laravel is one of the best dev experiences. Having used Django, fastapi, and built a custom server with golang, its still my go to for off the shelf fullstack crud apps.

Re: PHP 8.1.0

#114

Post by rbanffy »

iamphilrae wrote: post #103
rbanffy wrote: post #77

Genuinely curious: who here thinks PHP is a good choice for a new project and also has experience with other languages such as Scala, Kotlin, Python, or JavaScript and their respective web frameworks?

If it is what you/your team are most confident in and it is suitable to solve the problem (i.e a typical MVC web application), then yes, it is a very sensible choice. If your confidence lies elsewhere, then no, choose that instead. End of the day you’re just solving a problem using code.

True, but that’s self reinforcing. The more you use a hammer, the more confident you become in everything being nails.

Re: PHP 8.1.0

#115

Post by Gigachad »

jonwinstanley wrote: post #109
Gigachad wrote: post #60

Earlier quoted context omitted.

One comment I heard at a programming meetup recently was "I hate how frameworks like laravel have brought PHP back in to popularity when we had the chance to finally kill it off". I do wonder if there really was value in salvaging PHP when we have a wealth of other languages and frameworks that do a perfectly fine job without any of the legacy mistakes sitting around.

Doubt there was a chance to “kill it off”, doesn’t it run over 50% of all websites?

PHP powers a couple of the software packages used by over 50% of websites. Mainly being Wordpress. Impossible to know but I would guess that new development of PHP sites is not such an impressive stat.

Re: PHP 8.1.0

#116

Post by Gigachad »

mschuster91 wrote: post #107
Gigachad wrote: post #60

Earlier quoted context omitted.

One comment I heard at a programming meetup recently was "I hate how frameworks like laravel have brought PHP back in to popularity when we had the chance to finally kill it off". I do wonder if there really was value in salvaging PHP when we have a wealth of other languages and frameworks that do a perfectly fine job without any of the legacy mistakes sitting around.

Which ones would that have been? Perl? Python? Java? JavaScript? Among that choice set, PHP is definitely the best contender.

I would say that Ruby on Rails is a pretty good candidate to completely replace PHP with.

Re: PHP 8.1.0

#117

Post by iamphilrae »

rbanffy wrote: post #114
iamphilrae wrote: post #103

Earlier quoted context omitted.

If it is what you/your team are most confident in and it is suitable to solve the problem (i.e a typical MVC web application), then yes, it is a very sensible choice. If your confidence lies elsewhere, then no, choose that instead. End of the day you’re just solving a problem using code.

True, but that’s self reinforcing. The more you use a hammer, the more confident you become in everything being nails.

And that’s when you become a master of your tools and can wield immense power with them! But in all seriousness, PHP is a good language, and coupled with a modern framework like Laravel, it’s great to use.

I’ve used it since 2002, and have recently got back into it properly after a decade in architecture roles, and it feels very welcoming and love using it. And I _have_ tried the whole JavaScript thing, but simply find it’s ever changing build tools, package managers, etc a pain. Just my opinion though.

Re: PHP 8.1.0

#118

Post by ipaddr »

rbanffy wrote: post #77

Genuinely curious: who here thinks PHP is a good choice for a new project and also has experience with other languages such as Scala, Kotlin, Python, or JavaScript and their respective web frameworks?

Kotlin is for Android apps. Scala is a Java replacement. Those frameworks are unrelated.

Are you talking about building an Android app?

I've built app in different Javascript frameworks. Angular, Vue, React.

If I was building a website I would use PHP over Python, Golang or Javascript frameworks because what you get out of the box doesn't compare.

Each language does something well. If I was building AI python would be my first choice.

Re: PHP 8.1.0

#119

Post by message »

bilal4hmed wrote: post #3

I haven't written PHP since the 5.0 release but its amazing to see how it has grown over the years. Seems to have picked up a few nice things and is still enjoying usage even today.

Same, but it looks like they are trying to make Java out of it.

Re: PHP 8.1.0

#120

Post by 0x4d464d48 »

stefanos82 wrote: post #104
0x4d464d48 wrote: post #87

Earlier quoted context omitted.

Say what you will about JavaScript... I use it constantly not because it's well-designed but because TINA (there is no alternative). [] == ![]; // true. Go ahead. Run it in your console...

...so it basically is `0 == ![]`, in other words, `[].length` which is `0`, thus becomes `0 == false` which returns `true` with loose comparison?

Yep.

Because an array is an object which has a 'truthy' value '![]' evaluates as 'false'.

Simplifies to a statement similar to 'false == false'.

A little useless arcana for those interested.

Well, not so useless if your expecting '!someEmptyArray' to evaluate to 'true'. Use '!someEmptyArray.length' instead.

Post reply on HN