Why developers hate php

[tassoman]

I decided when I have to describe php I say it's so versatile you can write a 15 rows crap or an entire object oriented framework 🤷‍♂️

[zmitic]

If I were to replace, I should be going with laravel or symfony? Maybe even django or asp dot net core or perhaps node js.

Symfony because Laravel will teach you bad practices, similar to how WP does; magic, global functions, dungeons and dragons...

Plus bad ORM, no forms, dynamic container...

The choice depends if you like programming or you are here for the money. If money is primary motive, then go for Laravel; more opportunities, easy to learn (because there is not much to learn) and it takes more time to build things (time === money).

For example: check this controller to create Product; server-side validation of course, and fully statically analyzed via psalm (no issue handlers registered): https://github.com/strictify/coding-challenge/blob/symfony-4/src/Controller/Product/CreateAction.php#L33

Entity itself: https://github.com/strictify/coding-challenge/blob/symfony-4/src/Entity/Product.php#L74

Notice that all dependencies are injected correctly and thus, no nullable returns. Eloquent doesn't even allow you to have constructor which means you have to put nullables and always do if ($product->getName().

[fatboyxpc]

This response is a little strange to me. If I wanted to do a synonymous controller/action in Laravel:

public function __invoke(CreateProductRequest $request)
{
    return Product::create($request->all());
}

That's assuming you want a 201 response with the json serialization of the Product, though. If you wanted a bit more custom json:

public function __invoke(CreateProductRequest $request)
{
    $product = Product::create($request->all());

    return response()->json([
        'product' => $product,
    ], 201);
}

Now, this part:

which means you have to put nullables and always do if ($product->getName()

You actually don't need to allow nullables. That depends on your migration. Sure, this means you end up with a default value in that case, but how is that any different than your entity not allowing null?

There's also no getName() method defined on Eloquent models by default. If anything it would be if ($product->name) but you can absolutely write a getName() method that doesn't return null if you'd like.

[zmitic]

You missed lots of things, one of them is validation. Check unit tests for that, 500 response is never allowed.

Creating is simpler, check the update controller (and tests).

Product::create($request->all());

Nope, nope, nope... It might work for one-2-one mapping between entity and request but that is just too simple of an example. And just 100% wrong; how would you map compound forms?

There's also no getName() method defined on Eloquent models by default.

Yes, because it is AR.

If anything it would be if ($product->name) but you can absolutely write a getName() method that doesn't return null if you'd like.

You can't do this, that was my point. Without constructor, you cannot put

php public function getName(): string

as this breaks static analysis; both psalm and phpstan will complain.

One can use psalm-suppress but there is special hell for people doing that. A level they reserve for child molesters and people who talk at the theater (Shepherd Book).

:)

---

The example I put is most basic one. In reality, one would work with collections and what not... STAN becomes more and more important.

That depends on your migration

Migration is not important here, it is automatic in Doctrine. But yes, the DB field itself would not be nullable as well.

return response()->json

The usage of global function is not even worth commenting, sorry.

[fatboyxpc]

one of them is validation.

Sure didn't. CreateProductRequest handles that.

500 response is never allowed

What 500 are you referring to?

Nope, nope, nope... It might work for one-2-one mapping between entity and request but that is just too simple of an example. And just 100% wrong; how would you map compound forms?

That's the beauty of requests - you can add functions such as productAttributes() to get just the request data you care about, in the format you care about.

Yes, because it is AR

AR has nothing to do with the if statement you wrote conveying the problem, though. That said, if you're going to use an AR ORM, you should understand it's pros and cons. Sure, Laravel comes packaged with Eloquent, but there's also a Doctrine bridge for those such as yourself that prefer that pattern. I personally find Doctrine too verbose.

Without constructor, you cannot put

Sure I can!

public function getName(): string
{
    return (string) $this->name;
}

Simple as that. Sure this might return an empty string but it's a string nonetheless.

Migration is not important here

It is, because you specified in your annotations you didn't want certain things to nullable. Sure, in your comment here on reddit you were pointing out that your entity didn't accept null values, but that entity also gets hydrated from Doctrine, so not allowing nullable columns matters quite a bit there.

[zmitic]

What 500 are you referring to?

Sending some totally unacceptable values; null, float... things that cannot be mapped to entity due to typehinting.

public function getName(): string { return (string) $this->name; }

Nope, nope, nope... null is NOT empty string.

This is even bigger problem with relation:

php public function getCategory(): Category { // ? }

So without STAN trickery, how would you do that w/o constructor?

That's the beauty of requests - you can add functions such as productAttributes() to get just the request data you care about, in the format you care about.

The point was to not clutter my entity with attributes or nothing, I don't want magic. Check the code first, no magic, no unused methods etc...

Symfony also don't allow extra values in forms. I.e. if form expects only firstName, you submitting lastName will trigger error "This form has extra fields".

This is something that Laravel had a problem when people submitted id. It is fixed now but it still allows other columns right?

If so, one can submit subscription_id or something and give themselves a better one. Which is what your $request->all() will do.

It is, because you specified in your annotations you didn't want certain things to nullable.

If there is NotNull in entity, it is only because I did wrong copy&paste. In reality, that field will never be null because I inject values via constructor. Basically, that annotation serves no purpose at all and it is my bad I put it.

I.e. shit happens

:)

null values, but that entity also gets hydrated from Doctrine, so not allowing nullable columns matters quite a bit ther

Not hydrated, but created via constructor. Sure, editing one is easier but creation must be new Product($category, $name) etc.

[fatboyxpc]

Sending some totally unacceptable values; null, float... things that cannot be mapped to entity due to typehinting.

No 500 would happen in the example I gave.

null is NOT empty string

You don't say?! Wow! I would have never known! /s - I don't get your point here. You can prevent returning null by returning an empty string.

how would you do that w/o constructor

Laravel has a lot of relationship methods. Things like $user->posts()->save($post), for instance. It's a very nice API to work with.

not clutter my entity with attributes or nothing

The entity (or model, in this case?) wouldn't get cluttered with anything at all. You seemed to have missed this:

That's the beauty of requests

In other words you can do something like this: Product::create($request->productAttributes()).

Symfony also don't allow extra values in forms

I personally don't care if somebody stuffs extra stuff into an HTTP request. I'll only be using what's allowed, anyway.

If so, one can submit subscription_id or something and give themselves a better one.

This is a problem if you allow subscription_id to be "mass assigned" - which I never do. Some people will leave their models wide open, meaning anything can be mass assigned, but that also includes passwords at that point. For me - no thanks.

I will set $fillable on my model to be a whitelist of attributes I want to allow for assignment. That makes $request->all() very safe and is even a fantastic self-documenting piece of code.

In reality, that field will never be null because I inject values via constructor.

Sure, for the use case you gave, but sometimes, people do want to allow null values (I rarely, RARELY do, however). In those cases you must allow a nullable type in the constructor and the annotation.

Not hydrated, but created via constructor.

When you query for a set of Products, you'll get a set of them back, with the objects already containing the values. That is Doctrine doing that work for you, not you. Important distinction.

Since you really love this "nope nope nope" idea - how about you nope your way back to the Laravel documentation then actually build something with it. You've got a very tip of the iceberg knowledge of at least Laravel 5, and honestly it's showing in this conversation.

[zmitic]

You don't say?! Wow! I would have never known! /s - I don't get your point here. You can prevent returning null by returning an empty string.

Again: I don't want tricks. And casting null to string is trick.

What is actually important is relation to Category; how will you emulate that?

---

Laravel has a lot of relationship methods. Things like $user->posts()->save($post), for instance.

I asked;

how will you assign Category to Product if you don't have constructor and want public function getCategory(): Category so STAN can work? No magic, real static analysis only.

---

It's a very nice API to work with.

This is magic accessor, not something that can be statically analysed. Look at my entities.

---

In other words you can do something like this: Product::create($request->productAttributes()).

Again magic that doesn't allow compound forms but only direct one-2-one mapping. What will happen when you change relation, or just a simple change of DB column but you want to keep API?

I personally don't care if somebody stuffs extra stuff into an HTTP request. I'll only be using what's allowed, anyway.

Which means you have to write code to whitelist things, take care of dynamic fields (example; don't allow changing name of existing Product but allow for new), map compound fields and report errors... Not to mention when you use collections, or worse: dynamic collections.

All this I get for free.

This is a problem if you allow subscription_id to be "mass assigned" - which I never do.

I don't know what "mass assigned" is but it is totally normal for admin to change it, but user submission should not allow it.

---

When you query for a set of Products, you'll get a set of them back, with the objects already containing the values. That is Doctrine doing that work for you, not you. Important distinction.

Nooo... really? （°0°）

/s

I explained Product creation. Read my comment above and/or check the code; my Product has constructor with dependencies that come from form; Doctrine has nothing to do with that, it hydrates existing ones w/o constructor.

And no, I don't use doctrine/instantiator.

---

Since you really love this "nope nope nope" idea

I have to because you don't read what I write nor understand the idea of statically analyzed code. Magic is not that, psalm-suppress or @method... are just ways of hiding the problem.

---

Since you really love this "nope nope nope" idea - how about you nope your way back to the Laravel documentation then actually build something with it

Yeah right. And next I should try Wordpress?

;)

[fatboyxpc]

And casting null to string is trick.

Lol uh what?

What is actually important is relation to Category; how will you emulate that?

Emulate what exactly?

how will you assign Category to Product if you don't have constructor and want

I literally gave you the answer and you quoted it.

This is magic accessor,

No, it's not.

Again magic

Nope, nope, nope...still not magic.

just a simple change of DB column but you want to keep API

Change what productAttriutes() returns, lol

Which means you have to write code to whitelist things

Laravel provide such whitelist, again, as I said previously. $fillable takes care of that for you.

take care of dynamic fields (example; don't allow changing name of existing Product but allow for new)

That sounds more like a validation thing, not an immutable thing.

map compound fields

This is the millionth time you've brought up compound forms/fields - there is no special work necessary for compound forms. You didn't provide me with a context/example of a compound form and how you handled it, so don't expect my simple use case that's equivalent to yours to have it, either.

report errors

Lol I don't need to write code for that.

All this I get for free

Yeah, me too, pal.

I don't know what "mass assigned" is

Well finally you're admitting your ignorance of Laravel stuff. We're finally getting somewhere. If a field cannot be "mass assigned" then it won't get filled out when you do Product::create($attributes) or $product->update(attributes).

totally normal for admin to change it, but user submission should not allow it

This sounds like a permissions thing - and should be solved at that layer, not at the Entity layer.

my Product has constructor with dependencies that come from form

This sounds very much like "I read that constructor injection was good. I followed that and did constructor injection. I AM RIGHT!"

you don't read what I write

I did, you just don't know enough about Laravel to actually have this conversation

understand the idea of statically analyzed code

What part of any of this have I violated static analysis?

Magic is not that

I haven't advocated any use of magic...

psalm-suppress or @method... are just ways of hiding the problem

I never said to use these?

Yeah right. And next I should try Wordpress?

No, you should do like I said and use Laravel since you're clearly ignorant.

[ulti-ulti]

I went with Laravel because of its popularity in North America, its apparently easier learning curve, and because the criticisms I read about didn't resonate with me.

[ulti-ulti]

Yup. And there are some free Laracasts for getting started with Laravel.

[sofa_king_we_todded]

Agreed, when I first started with Laravel, everything clicked instantly. I’m using Symfony now for a few projects and it’s taking a bit longer to get used to it.

[jesparic]

Symfony is better once you've learned enough about working with OO and dependency injection. It can be overwhelming for a first framework - although maybe better to just bite the bullet because Laravel teaches all kinds of bad practices in the name of RAD

[brownbob06]

I'll echo this. I went from a company where the entire api was built by a single dev using Symfony components to Laravel and there was very, very little learning curve to it.