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

PHP in 2023

stitcher.io

Post reply on HN
Print view View original

241–250 of 285 posts

Re: PHP in 2023

#241

Post by pocketsand »

bakugo wrote: post #239
pocketsand wrote: post #211

Earlier quoted context omitted.

You can look at a Laravel (Eloquent) model and easily see what methods it has. Nothing is hidden -- at least no more than any ORM that inherits from another class which gives it functionality. As for properties -- yes, they're not explicitly described but mapped to the database schema. Other ORMs, like that in Ruby on Rails, also do not explicitly set model properties and just map to database columns. People have bee…

The only benefit you've mentioned is writing less code. Which just proves my original point about Laravel being for people who want to get things done as fast as possible with the minimum effort possible, regardless of how much sense it makes. >Consider Django. There, you explicitly define properties, but link them to the type of database column they'll use. Then, you can generate a migration based upon the model, an…

When I work in Django, instead of other frameworks I use, I think "I like this more, I like this less; this works better for me in these circumstances, this does not." But I've never felt it made any sense at all to pronounce one as objectively better than another.

In most cases, it is a matter of taste and tradeoffs that vary based upon circumstance.

You can keep saying "this is the correct way" with all the conviction in the world, but it won't turn matters of opinion and circumstance into universal fact.

Re: PHP in 2023

#242

Post by berkle4455 »

awestroke wrote: post #170
phphphphp wrote: post #164

Earlier quoted context omitted.

You can quote yourself ad nauseam but that does not turn your incorrect statement into a correct statement. If you spent any amount of time looking at a modern PHP codebase, you'd discover that the type of code people write today is radically different to the type of code you'd have seen at the time A Fractal of Bad Design was written. There are still aspects of modern PHP that stand to be improved, absolutely, but t…

Your argument is basically: "Yes, yes, the footguns are still there front and center, but we added more guns that don't shoot you on the foot." If I was using PHP, I'd be livid that the cruft is never removed. Just deprecate and remove it

http://maettig.com/2020-09-16-revisiting-a-fractal-of-bad-de...

Nearly every point in the original blog shown to be solved here.

Re: PHP in 2023

#244

Post by BuckyBeaver »

pocketsand wrote: post #168
BuckyBeaver wrote: post #110

Earlier quoted context omitted.

Looking at the Laravel site, I’m concerned about Laravel’s reliance on an ORM. Not only because ORMs are widely derided, but because I have a legacy MySQL DB and PHP 5 project I want to resurrect. I’m down to rewrite the server, but how do I restore a database full of user data with Laravel?

I work on a project like this and you'll run into some papercuts, but it's not hard. You can take a model for anything in your legacy code, and just set properties on the model to teach Laravel how to deal with things that don't follow conventions. For example, you can override the table name. Suppose you had a legacy table called "postdata". In Laravel, this table would be called posts, and a model would be Post. So…

Great, thanks! I’m pretty psyched to get started, after reading these comments.

Re: PHP in 2023

#245

Post by BuckyBeaver »

cellover wrote: post #182
BuckyBeaver wrote: post #126

Earlier quoted context omitted.

Not sure what you mean by classic, but I designed it manually to be queried with plain SQL. So I suspect the answer to your question is yes. Thanks for the info!

By classic I mean something somewhat standardized like user table: id, name, email ; post table: id, user_id, content etc.

Pretty much, then, yes.

Re: PHP in 2023

#246

Post by koonsolo »

shkkmo wrote: post #236
koonsolo wrote: post #227

Earlier quoted context omitted.

For reference, I'm working with both React and PHP. And yes, for example WordPress uses React components. I'm a 42 year old software architect. But hey, maybe I've been ignorant all this time. React vs PHP is a decision you can make, because... the intention of both is to output HTML. edit: > The easiest way to explain it is that you could reasonably use react within a PHP project. I can use C within a Python project…

> React vs PHP is a decision you can make, because... the intention of both is to output HTML. Often PHP is used when no HTML rendering happens at all (Apis, scheduled jobs etc.) > I can use C within a Python project. Does that mean I can't compare the two? One is compiled while the other is interpreted, so maybe you can't compare those? Those are at least both programming languages. Several major python libraries ar…

> Often PHP is used when no HTML rendering happens at all (Apis, scheduled jobs etc.)

When comparing to React those things are irrelevant.

> the complaint was that PHP, a server side language, doesn't offer client side rendering built in.

So am I allowed to compare server side rendering to client side rendering? Or are those 2 different things and I'm ignorant if I try to compare them?

Re: PHP in 2023

#247

Post by makeitdouble »

jbboehr wrote: post #221
makeitdouble wrote: post #152

Earlier quoted context omitted.

I’m in agreement with you that it came a very long way. Now, most of those have been present in many other languages [0], often with less limitations. And as usual the old ways haven’t all been deprecated either, so it stays weird. For instance typed properties were a chance to reset the clock on type handling, but no, declaring a type will force cast parameters to that type instead of throwing an error (i.e. passing…

> declaring a type will force cast parameters to that type instead of throwing an error There is `declare(strict_types=1)`[0] [0]: https://www.php.net/manual/en/language.types.declarations.ph...

Yes, except it has to be set on the _caller_ side.

I kinda see why, after all it’s the caller who will deal with the TypeError. But assuming we’re not setting types for all our functions, when I do for a specific one, I want to enforce that strictness on the _callee_ side (“for this function, it really matters that the parameters are correct”), and not have to go check if every single caller files properly has the strictness set. [0]

So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.

[0] Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system. And it still doesn’t work for native functions.

It’s so close. Really, so close to be good.

Re: PHP in 2023

#248

Post by jbboehr »

makeitdouble wrote: post #247
jbboehr wrote: post #221

Earlier quoted context omitted.

> declaring a type will force cast parameters to that type instead of throwing an error There is `declare(strict_types=1)`[0] [0]: https://www.php.net/manual/en/language.types.declarations.ph...

Yes, except it has to be set on the _caller_ side. I kinda see why, after all it’s the caller who will deal with the TypeError. But assuming we’re not setting types for all our functions, when I do for a specific one, I want to enforce that strictness on the _callee_ side (“for this function, it really matters that the parameters are correct”), and not have to go check if every single caller files properly has the st…

> Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system

There was this RFC[0] but it seems to have fizzled.

> And it still doesn’t work for native functions.

The page states: 'Function calls from within internal functions will not be affected by the strict_types declaration' (emphasis mine). Outside of array_map I don't think this happens all that much.

> So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.

That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?

[0]: https://wiki.php.net/rfc/namespace_scoped_declares

Re: PHP in 2023

#249

Post by mike503 »

I miss the simple days. I want a PHP that has no classes (procedural only), stops around 5.6 for its syntax (none of these shorthand things) and fixes some of the needle/haystack and function naming inconsistencies. Just give me strings and arrays and floats/ints. I'll add in named parameters, but I think that's the only new thing I'd want to take.

Anyone want to go in with me on that?!

Re: PHP in 2023

#250

Post by mike503 »

mike503 wrote: post #249

I miss the simple days. I want a PHP that has no classes (procedural only), stops around 5.6 for its syntax (none of these shorthand things) and fixes some of the needle/haystack and function naming inconsistencies. Just give me strings and arrays and floats/ints. I'll add in named parameters, but I think that's the only new thing I'd want to take. Anyone want to go in with me on that?!

Oh and for everything else in the normal PHP world, I tell people to use a framework, and for that framework I tell them to use Laravel. Period. To me it's the jQuery for modern PHP (note: I don't even code using it myself, but I tell people to have their dev team start with it)
Post reply on HN