unknown

Explores PHP's philosophy and design principles, highlighting arrays as a core feature that makes PHP distinctive. Arrays in PHP are versatile data structures that can store any type of data, are simple to manipulate, and efficient to iterate over, making them the preferred method for data transfer in the language.

The PHP Way of Life

Welcome to PHP Dev, a dedicated space for sharing knowledge about PHP and its ecosystem (only PHP directly related).
Help us find good articles and blogposts and provide links. Upvote or downvote, after reading, it's essential

PHP Dev

I strongly disagree with this; it betrays its entire premise to begin with.
The first thing it states (and I agree) is that PHP is a language that embraces everyone from the hobbyist to the elite corporations, but then all the rest of the text is saying how badly the language evolved because it drank from sources that aren’t as simple as it originally was; it added features that make sense for large and complex projects but not for the simpler ones; and it spans arguments that sound like it’s either a beginner that only knows how to write procedural code, thus, of course, it’s the simpler code to read, or it’s some dude that really loves procedural programming and blindly hates everything else, attacking strawmen.
This makes the text really hypocritical because it argues that the PHP philosophy is being a language for everyone, but the real argument is that PHP should remain a language only for beginners and hobbyists.
The OO section in special is the thing I disagree with the most; it’s full of strawmen and critiques things that aren’t even OO problems but problems related to forcing procedural thinking into OO to begin with.
OO isn’t Simula; the language didn’t really offer anything new to the scene at the time. Most of the “OO” concepts were about how procedural languages were already evolving and being widespread, like how Modula-2 already had encapsulation. The Simula inheritance comes from the Hoare Records paper, and the most groundbreaking idea of OOP that changed how we think and model systems, the ADTs (what we would call abstraction in the 4 pillars), was an independent orthogonal area of research, and we already had that since forever; we called them structs.
What “OO” brought to the table was systematizing these years of innovations and knowledge of building systems into a new paradigm of software engineering, not a new paradigm of programming. Before we designed systems, we decomposed them into smaller algorithms, from routines to sub-routines. For this, flowcharts were enough, but anyone who tried to design something more complex, trying to model real-world business rules and so on, knows this hits the limit really fast. Thus, the new approach to design systems was decomposing things into the domain, representing the domain concepts with ADTs, and thinking about what operations belonged to each concept. Thus, the class feature that OO languages had naturally became a fit mechanism to represent these new, better designs.
But if we analyze well, this is just an extension of procedural programming but at scale. We already had modules; this is basically the next step. The classic 3-layered architecture with data, domain, and presentation layers is the most procedural thinking applied to system architecture. It only represents a flow in which each procedure is called, each one addressing a concern as per SoC (another structural/procedural gift to the world).
If we take only the Simula model as a basis, we don’t have a new computation model; you don’t think the execution model is as different as you thought before, thus leading to discussions if o.f() is just syntax sugar for f(o), and when these assumptions are true, you have languages like Modula-3 and, in parts, Python and PHP.
The thing that saves PHP and Python is that both have strong meta-programming mechanisms and ways to implement real message passing baked into their object models (the __call magic method), so they indeed can be used to implement OO.
OOP is what Alan Kay created with Smalltalk, programming with self-contained entities that have encapsulated state and that only act with message passing. This is indeed a different model of computation that makes it so. f() is different from f(o) and makes us design things in a very different set of logic.
It turns out that Alan Kay’s model scales really well; any messaging application with long longevity, like WhatsApp or the USA telephone system, is made on top of message passing (even though these use the actor model, the models are really close to each other), and what we do with microservices today also only works because message passing is a really great computation model for distributed programming.
Back to the post, the author argues that OO is verbose, but this is very relative, and, in many ways, OO can be much less verbose than even FP and procedural code. Take the following code for example:
<pre><code class="language-php">foreach ($users as $user) {
 deactivate($user);
}
</code></pre>
This is the procedural version; it takes whole 3 lines of boilerplate to do this. Meanwhile, the FP approach
<pre><code class="language-php">$users |&gt; forEach(deactivate(...));
</code></pre>
Thanks to the new pipe operator, it reads really nicely, to me even easier than the procedural version since it focuses on what, not how, and it’s more concise; it fits in one line.
<pre><code class="language-php">$users-&gt;each-&gt;deactivate();
</code></pre>
This is as concise as the FP version, but even more readable; it reads like natural language. Anybody, even people who don’t program, can understand what this code does because it reads like a phrase that anybody learns how to read in school. I cheated a bit by using HOMs that are a really niche pattern, but, hey, they’re available as part of the Laravel collections API, so I think that’s a fair case that most developers have access to this today in PHP.
The sources for this section are also quite strange; one statement comes from the Clojure creator, so of course it prefers the types of trade-offs that come from FP languages. From this view, OO looks like a lot of overhead, but the same can be said if you look at any paradigm with the lens of another paradigm without understanding why things happen that way in these computation models and what trade-offs these bring to us.
We can say that FP is bad because to even make something as simple as mutating a variable, we need to be professional mathematicians that understand category theory and monads. Just because we want to avoid the most basic operation, which is mutating a value, our minds think of state changes, yet FP doesn’t allow us to write code that mutates things. See? This is a super strawman that doesn’t play into FP strengths and only downplays them without understanding the whys. So, while OO has a lot of valid criticism, most of it isn’t really directed to the core and is done because the person already has an answer in mind instead of considering the other ways to model problems.
The other source it mentions is a Intel dev that talked mostly from a domain that surprise, surprise, its dominated by structured/procedural code, and its in this domain that it really performs well, so of course it would have skewed view of OO.
It mentions problems with control flow interpretation, but this is the exact entire point of procedural/structured programming, code managing control flow, so of course if you always think by these lens even FP looks a bit worthless.
To add to that, while i can agree that control flow in OO is more confuse, since this is the point of message passing, what you get is really worthy and if you consider this, the critic it do at the beginning that if misused is bad, it holds true for OO too.
With OO, you get the correct responsabilities placed, even control flow ones, that is something that neither procedural neither FP do, this is because neither of them has the concept of a receiver, so the only place to add control flow logic is adding another layer on top of your logic, being simply control flow pushed to the client (so if you ever have to reuse this, you need to jump into the method hell it describes or worse have duplicated code accross all the codebase), in FP at least this is limited to composing into the pipeline, but in procedural you really pushes the responsabilities to the client and pray that things work well, its easier to analyze and spot-on if is wrong, yes, but it comes at the cost of the logic being in a unrelated place.
In message passing systems, the flow itself is harder to see, but the coordination is placed respecting everyones limits, nobody does more than it should, so you can program with confidence that inside the context of the class you can analyze everything you need to understand how that code works, so you don’t really have the necessity to understant the entire flow like in procedural, thus mitigating this problem. This is TDA (Tell Don’t Ask) really well applied in OO.
It also mentions a guy that is ranting about why ORMs weren’t all like what Prisma is to JS today, and blames OO for that when its like having a problem and blaming another thing that isn’t the cause of the problem, at the end it shows a code that he says would scary Smalltalkers, but its the most Smalltalk style code done, not like any procedural programmer would think about code, so it ends with a contradiction where the solution it proposes its what the purest OO code would look like.
At the separating data and logic section, it argues that data and operations should remain separate, that programming is about verbs not nouns, and this is a contradiction in itself, because if you have data and behavior logically you have nouns and verbs, since verbs can only express behavior, if you only have behavior, you’re trying to do dataless programming, and guess what this means? Yes, OOP, you try to get rid of the data, so you can program only at an abstract level by specifying what operations happen at that point, the very thing being criticized later.
OOP does let data be data and behavior be behavior, this is why you send messages to object, the objects themselves are passive, and only act when you send them a message to do something.
Even FP at scale resambles OO, because it becomes a form of actor model. Every distributed model resambles some messaging system.
This particular quote is contradictory:
<blockquote>
There’s no objective and open evidence that OOP is better than plain procedural programming. OOP is not natural for the human brain, our thought process is centered around “doing” things — go for a walk, talk to a friend, eat pizza. Our brains have evolved to do things, not to organize the world into complex hierarchies of abstract objects
</blockquote>
It says that isn’t natural for human brain, yet all the examples imply a subject, since we model our language like this, thus we think the way our idiom is modeled after, its a philosophical understanding that the language models how you perceive the world, so if our language assumes SVO, then naturally OO is what models this best, not worse, yes, we thing in terms of doing thinks, the part this quote fails to realize is that we always assume a subject doing these things, and by having the concept of a receiver of a message, OO is who models this the best, because not only you have the V (the message), you have the S too (the object).
The Procedural vs OO section is perhaps the most ofensive. It uses Yegor works as basis, but everyone that reads his blog often knows that what he means with OO is very different than what everyone else including Kay thinks is OO, his “true OO” is much closer to FP than OO really.
Despite this critcism, the autor always argues that the procedural example is more readable when at best that is only an preference argument. I genuinely can’t understand how anyone would think a foreach loop would be more readable than declaratively saying that you’re working with the FileLines, but i digress…
Yegor writes declarative code, its just a style difference really, and most literature and common sense agrees that the simpler and most readable code is often the declarative code, not the imperative one, this is why people thing HTML and CSS are easy and JS is hard.
So the state of art implies that Yegor version would be better, but even if you don’t believe this, at best, this boils down to preference, you can’t really say procedural code would be more readable in most situations, and the examples given are really not that.
To finish, let me show Smalltalk-like solution for those problems, what i think its much more readable than the procedural version at least.
First to the max problem:
<pre><code>$max = max(10, 5, 4, 2)
</code></pre>
<pre><code>$max = collection(10, 4, 5, 3)-&gt;max()
</code></pre>
For this, it doesn’t make much difference, but i think having max as a method of collection its much better since you can even make it compatible with other types by implementing a compare protocol in objects accepted by this collection while max function is tied to numbers, so if you have a school domain and need to handle grades of the students you can’t implement a custom predicate that makes the code more readable like it would be with HOMs or HOFs:
<pre><code class="language-php">// HOFs
$students |&gt; max(byGrade(...));

// HOMs
$students-&gt;max-&gt;grade;
</code></pre>
In these cases it becomes more obvious who is more readable.
For the transform file, i probably would model like this inspired by Smalltalk considering that by reading the contents you get a HOM to handle the Stream:
<pre><code class="language-php">function transform(File $in, File $out): void
{
 $in
 -&gt;contentsOfEntireFile
 -&gt;collect
 -&gt;trim
 -&gt;writeOn($out, withEncode: &#x27;UTF-8&#x27;);
}
</code></pre>
I think this one is quite readable, and it has the benefit of not needing to deal with knowing that the destination file is an array list of the size of the read lines, that’s quite an implementation detail that distracts you of the main logic of this operation.

Some pseudo intellectual fluff about what this guy thinks development in PHP should look like. The moment you see a “Manifesto” you know this guy is drinking too much of his own cool aid.
Sounds like communism … don’t recommend