@symfonystation The information in the article are pretty outdated and/or incorrect. The linked bug tracker is no longer in use, the 50%+1 majority no longer exists. The linked example RFCs are not a good representation and two of them are not implemented or even voted on, despite the article claiming the the listed RFCs have been "implemented over the years". Based on the “Certification” link at the end, I suspect that this is pure SEO spam.
You’ve missed out on the biggest feature in PHP 8. With named arguments it’s now possible for arguments to be provided in any order. You can now have functions with a large number of optional parameters, without creating a total shit show.
Sadly, no explanation whatsoever of why this approach might be better than just building the object yourself. The example provided is fairly trivial and doesn’t seem to justify using a builder.
Also, how would you do validation of properties (or even detect incompatibility of some of them)? Surely, because Productcan be created directly, the Product class itself should validate its values. But it also makes sense for the ProductBuilder to have its own validation, right? Would that mean doing the validation twice?
The article tries to sell the pattern as being your best friend, but at the same time doesn’t say how that’s gonna happen.
The main advantage of a builder is you can create an object in multiple steps instead of one step.
During the builder process the object might temporarily be in an invalid state - for example perhaps you can’t easily access the product price. You wouldn’t want price to be an optional value for the actual product class, but it can be optional for the builder (as long as it’s set once build() is called).
In strict_types mode, passing a string will throw an exception. In the default mode (including in PHP 8), the string will be silently cast to an integer.
HTTP values are always strings. So that code will only work with strict types disabled… and there is a lot of PHP code in the world that relies on this arguably “bad” behaviour.
I’d bet one day strict types be enabled by default. So if you want your code to be future proof… get used to enabling it now for all new files. Also I agree with @Dwoncount - you should really be using JSON instead of $_POST. And your JSON should have integer values, not strings.
Pretty happy with a smaller incremental release. The only feature I see myself using immediately will probably be typed constants, but I like the datetime exceptions and json_validate as well.
@symfonystation The real issue here is that too many PHP applications are not configured to work with a single PHP entrypoint, instead, they enable any dot php file to be served. This is criminal often, specially on nginx where you can't ship these rules like Apache (an .htaccess file on web root) and users share their own rules without realizing the hazardous conditions.
@symfonystation I don't get it, are loops now evil? Why would one want to not use them? Stuffing arrays into collections in order to manipulate them "nicely" is not a crime, sure. I just have a problem understanding why the other way is presented as bad/no-no.
PHP
Oldest