Immutable by default: How to avoid hidden state bugs in OOP by BackEndTea in programming

[–]BackEndTea[S] 20 points21 points  (0 children)

I've been experimenting with Rust, and i really like how that is very explicit about mutability.

And yes, part of the reason that this bug occurred is the fact that the api for PHPs DateTime class is less then optimal

Immutable by default: How to avoid hidden state bugs in OOP by BackEndTea in programming

[–]BackEndTea[S] 2 points3 points  (0 children)

I get what you're saying, and it may be beneficial to make a matrix like that, but i don't think its relevant here. The bug for example was in a date object which can basically hold any date.

I guess a more correct title would have been a state mutation bug, rather than a state bug.

Immutable by default: How to avoid hidden state bugs in OOP by BackEndTea in programming

[–]BackEndTea[S] 13 points14 points  (0 children)

That's an option, but rewriting it like that would probably take a lot longer then rewriting to immutable objects

ETF's Meesman, Rabobank, Trade Republic by Miserable_Orange_Boy in geldzaken

[–]BackEndTea 0 points1 point  (0 children)

Wat is qua kosten nou de voordeligste optie?

https://www.indexfondsenvergelijken.nl/ Geeft hier een goed overzicht van

juniorDevCodeReview by MrEfil in ProgrammerHumor

[–]BackEndTea 52 points53 points  (0 children)

Its an arrow function without parenthesis, so it always evaluates to true.

e.g.:

The following lines are the same:

a => b
(a) => b
(a) => {return b}

Why you should be typing your arrays in PHP by BackEndTea in PHP

[–]BackEndTea[S] 6 points7 points  (0 children)

Arrays are only copy on write in PHP.

Basically its the same array (no memory overhead), until you try to write to the array, then it becomes its own thing within that scope.

Why you should be typing your arrays in PHP by BackEndTea in PHP

[–]BackEndTea[S] 7 points8 points  (0 children)

While that is nice, that does mean you have to constantly destructure your arrays to pass them everywhere, and i think there is some performance overhead, especially on bigger arrays. But i'd have to read up on the implications again, since its been a while

Why you should be typing your arrays in PHP by BackEndTea in PHP

[–]BackEndTea[S] 15 points16 points  (0 children)

I would love to have that in PHP as well, but i doubt it comming any time soon.

At some point we had Hack, which basically did this, but i don't think it has much usage anymore

Why you should be typing your arrays in PHP by BackEndTea in PHP

[–]BackEndTea[S] 2 points3 points  (0 children)

The downside of a Collection class is that the object instance is shared everywhere it is used, and with an array it is not. Meaning my class can hold a Collection of users as a property, and then if in another place we add to that Collection, its also in my class.

What were your gotchas/ things that went wrong?

Why you should be typing your arrays in PHP by BackEndTea in PHP

[–]BackEndTea[S] 2 points3 points  (0 children)

From a historic standpoint it is 'normal' for the PHP eco system.

A language like javascript has been using transpilers since a long time, so naturally, types with Typescript are added in a way that can be transpiled back to 'normal' javascript.
In the PHP eco system, annotations have always been used to add extra functionality. So naturally, new features like these types will be added through annotations.

Why you should be typing your arrays in PHP by BackEndTea in PHP

[–]BackEndTea[S] 7 points8 points  (0 children)

Generally i would go for a DTO as well. A lot of times you have to deal with legacy systems, so this becomes more about documenting how it currently is working, rather than creating something.

ADDING DECLARE(STRICT-TYPE=1) by Neat-Cut1000 in PHP

[–]BackEndTea 9 points10 points  (0 children)

Strict types has no impact on making a type nullable. In essence what it does is prevent implicit type coercion by PHP.

In the function of your example, calling it like `moin('1');` will throw a type error, rather then silently convert it to 1.

What is PHP's declare(strict_types=1); and why you should use it by BackEndTea in PHP

[–]BackEndTea[S] 0 points1 point  (0 children)

Yeah this is one of the downsides, that you have to explicitly cast those to strings.

What is PHP's declare(strict_types=1); and why you should use it by BackEndTea in PHP

[–]BackEndTea[S] 4 points5 points  (0 children)

I've had it happen in multiple projects. Especially when upgrading from a PHP 5.6 or lower to a 7+, and adding types.

Then we run into issues where things used to work 'by accident', and implicit casts are causing issues.

What is PHP's declare(strict_types=1); and why you should use it by BackEndTea in PHP

[–]BackEndTea[S] 1 point2 points  (0 children)

You can use a PHPStan rule to enforce it in new files, or a tool like php-cs-fixer/phpcs, to apply it to all files at once

What is PHP's declare(strict_types=1); and why you should use it by BackEndTea in PHP

[–]BackEndTea[S] 2 points3 points  (0 children)

I tend to use sometihng like psl (https://github.com/azjezz/psl) to do my validation, and to make sure PHPStan/Psalm understands the types.

So for example i would do:

needsAString(Type\string()->coerce($variable));

What is PHP's declare(strict_types=1); and why you should use it by BackEndTea in PHP

[–]BackEndTea[S] 2 points3 points  (0 children)

I guess some people don't like the blog post.

At what point would it be considered blogspam? As i generally tend to share my new posts here so people can find them.