PHP Internals News: Episode 64: More About Attributes – Derick Rethans

PHP Internals News: Episode 64: More About Attributes

In this episode of “PHP Internals News” I chat with Benjamin Eberlei (Twitter, GitHub, Website) about a few RFCs related to Attributes.

The RSS feed for this podcast is, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:17

Hi, I’m Derick, and this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 64. Today I’m talking with Benjamin Eberlei, about a bunch of RFCs related to Attributes. Hello Benjamin, how are you this morning?

Benjamin Eberlei 0:36

I’m fine. I’m very well actually yeah. The weather’s great.

Derick Rethans 0:39

I can see that behind you. Of course, if you listen to this podcast, you can’t see the bright sun behind Benjamin, or behind me, by the way. In any case, we don’t want to talk about the weather today, we want to talk about a bunch of RFCs related to attributes. We’ll start with one of the RFCs that Benjamin proposed or actually, one of them that he has proposed and one of them that he’s put into discussion. The first one is called attribute amendments.

Benjamin Eberlei 1:05


Derick Rethans 1:06

What is attribute amendments about?

Benjamin Eberlei 1:08

So the initial attributes RFC, and we talked about this a few months ago was accepted, and there were a few things that we didn’t add because it was already a very large RFC, and the feature itself was already quite big. Seems to be that there’s more sort of an appetite to go step by step and put additional things, in additional RFCs. So we had for, for I think about three or four different topics that we wanted to talk about, and maybe amend to the original RFC. And this was sort of a grouping of all those four things that I wanted to propose and change and Martin my co author of the RFC and I worked on them and proposed them.

Derick Rethans 1:55

What are the four things that your new RFC was proposing?

Benjamin Eberlei 1:59

Yes, so the first one was renaming Attribute class. So, the class that is used to mark an attribute from PHP attributes to just attribute. I guess we go into detail in a few seconds but I just list them. The second one is an alternative syntax to group attributes and you’re safe a little bit on the characters to type and allowed to group them. And the third was a way to validate which declarations, an attribute is allowed to be set on, and the force was a way to configure if an attribute is allowed to be declared once or multiple times on one declaration.

Derick Rethans 2:45

Okay, so let’s start with the first one which is renaming the class to Attribute.

Benjamin Eberlei 2:51

Yeah, so in the initial RFC, there was already a lot of discussion about how should this attribute class be caught. Around that time that PhpToken RFC was also accepted, and so I sort of chose this out of a compromise to use PhpAttribute, because it is guaranteed to be a unique name that nobody would ever have used before. There’s also, there was also a lot of talk about putting an RFC, to vote, about namespacing in PHP, so namespacing internal classes and everything. So I wanted to keep this open at the at the time and not make it a contentious decision. After the Attributes RFC was accepted, then namespace

Truncated by Planet PHP, read more at the original (another 29493 bytes)

Relying on the database to validate your data – Matthias Noback

One of my pet peeves is using the database schema to validate data.

Several ways in which this normally happens:

  • Specifying a column as “required”, e.g. email VARCHAR(255) NOT NULL
  • Adding an index to force column values to be unique (e.g. CREATE UNIQUE INDEX email_idx ON users(email))
  • Adding an index for foreign key integrity, including cascading deletes, etc.

Yes, I want data integrity too.
No, I don’t want to rely on the database for that.

I find it surprising that some years ago we decided that we shouldn’t write application logic in our database (e.g. stored procedures) because:

  • They are not written in the same language as the rest of the project.
  • They are not version-controlled (unless you jump through some extra hoops).
  • They are not testable in isolation; you need an actual database to run them.
  • They are “magic” because they are triggered implicitly.
  • The code is vendor-specific.

Well, anyway, it’s clear that we don’t want them.

Yet, many of these concerns apply to validation at the database-level as well.
Except, with stored procedures we actually delegate some work to the database.
With validation, we usually duplicate the work.
We first validate in the code that a value has been provided and show a form error if it hasn’t.
Then we use an assertion in our model object to verify that a value is not null.
Then we save our object to the database, which again verifies that the value is not null.

Why do we do this?
Maybe because we want symmetry?
The model property is not nullable, so the column it’s mapped to should also not be nullable.
Maybe because we are more confident about the database than about our code?
In the code a validation might be skipped somehow, but we’ll always have that extra validation once the data ends up in the database.


I think we don’t need the symmetry, nor the safe-guard.
Instead, we should put more trust in our application code and make sure everything is handled there.
No need for the “double bookkeeping” where you try to keep the nullability of your model’s properties in sync with the nullability of the database columns.
In my experience often a model property is nullable, but the database column isn’t, or vice versa.
This leads to the application blowing up for a nullability discrepancy between the code and the database.
We can reduce this risk by stopping the double bookkeeping.
Instead of defining non-nullability on database columns, let’s only define it in the code.
We always have to deal with non-nullability in the code anyway, since we want validation errors instead of SQL errors.
So, let’s just remove NOT NULL everywhere, hooray!

Unique indexes

Another interesting database-level validation technique is ensuring uniqueness, like in the case of the unique email address in the users table.
Apparently, we don’t trust the application here either, and leave the verification of an important rule to the database (we’ll talk later about how important it really is).
Given that the database supports a uniqueness check by means of adding an index we jump in and add it to every column we feel should be unique.
We then realize that we don’t want SQL errors when a user registers with a known email address.
We want form validation errors instead.
Then we introduce some more double bookkeeping so we can be user-friendly and protect our data integrity.

What if we only validate the uniqueness of the email address in the application code and not in the database?
We could end up with two records in the users table that have the same email address.
It’s unlikely that this will happen though, because the application always runs the uniqueness validation itself, by querying the table for an existing record with the provided email address:

if ($this->userRepository->containsUserWithEmailAddress($emailAddress)) { // show form error in the response
} else { // the data is valid $user = new User($emailAddress); $this->userRepository->save($user);

The only way we could end up with duplicate records is when two registration requests providing the same email address are being processed at the same time.
In that case, the first containsUserWithEmailAddress() may return false during both of these requests and the call to save() would result in two records with the same email address.
Again, it’s not very likely, but it could happen.
But what if it happens?
We just have to make sure it has no significant impact.

I think the biggest fear when having duplicate email addresses in the database is that someone might b

Truncated by Planet PHP, read more at the original (another 8982 bytes)

Save your Drupal team hours and effort with Source Operations and Activity Scripts –

FleetOps—running a large fleet of apps and websites efficiently, securely, and predictably—is a challenge for every organization. One difficulty facing organizations managing multiple Drupal sites is keeping their dependencies current. For instance, each time a crucial security update is released, how many resources end up being spent making sure each site has properly been patched? How many team hours could be saved by automating dependency processes?
On, you can deploy your Drupal projects complete with a set of customized Source Operations that will automatically check for and apply updates using Composer to a development environment.

Byte-sized functional programming: Mapping out your data –

Byte-sized functional programming: Mapping out your data

Procedural code tends to think in terms of writing out steps, and so the usual way to work with a list is to iterate it using a `for` or `foreach` loop.

Functional code tends to think in terms of the relationships and transformations between data, where those relationships and transformations are defined as functions. That means the natural way to work with a list is to define a function that is the relationship between one list and another. The most common way of doing that is with a “map,” which in PHP usually means the `array_map()` function.

With `array_map()`, you give it an array and a function. You get back the result of applying that function to every element in the array, individually. Like so:

= [1, 2, 3, 4, 5];
$fun = fn($x) => $x * 2;
$result = array_map($fn, $arr);

The advantages of that over a `foreach` loop are:

* The function is a separate operation that can be as complex as you want.
* If it’s more than a line or two, make it its own function or method somewhere and test it in isolation.
* If it’s trivial, you can simply inline it.
* It’s clear, visually, that every element’s transformation is independent of every other’s, because that’s how `array_map()` works. A `foreach` loop may maintain state from one iteration to the next, but `array_map()` does not.

Want to know more about functional programming and PHP? Read the whole book on the topic: Thinking Functionally in PHP.

Thinking Functionally in PHP

27 July 2020 – 3:42pm

PHP Internals News: Episode 63: Property Write/Set Visibility – Derick Rethans

PHP Internals News: Episode 63: Property Write/Set Visibility

In this episode of “PHP Internals News” I talk with André Rømcke (Twitter, GitHub) about an RFC that he is working on to get asymmetric visibility for properties.

The RSS feed for this podcast is, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website:


Derick Rethans 0:16

Hi, I’m Derick, and this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 63. Today I’m talking with André Rømcke, about an RFC that he’s proposing titled property write/set visibility. Hello André, would you please introduce yourself?

André Rømcke 0:38

Hi Derick, I’m, where to start, that’s a wide question but I think I’ll focus on the technical side of it. I’m been doing PHP for now 15 plus years. Actually started in, eZ systems, now Ibexa, met with you actually Derick.

Derick Rethans 0:56

Yep that’s a long time ago for me.

André Rømcke 0:58

And well I came from dotnet and front and side of things. Eventually I learned more and more in PHP and you were one of the ones getting me deeper into that, while you were working on eZ components. I was trying to profile and improve eZ publish which what’s left of the comments on that that point. A long time ago, though. A lot of things and I’ve been working in engineering since then I’ve been working now actually working with training and more of that, and the services and consulting. One of the pet peeves I’ve had with PHP has been properties for a long time, so I kind of wanted several, several years ago to look into this topic. Overall, like readonly, immutable. To be frank from our side that the only thing I really need is readonly, but I remember the discussions I was kind of involved for at least on the sideline in 2012/ 2013. Readonly and then there was property accessors. And I remember and there was a lot of people with different needs. So that’s kind of the background of why I proposed this.

Derick Rethans 2:04

We’ll get back to these details in a moment, I’m sure. The title of the RFC is property write/set visibility. Can you give me a short introduction of what visibility actually means in this contract, in this context?

André Rømcke 2:16

Visibility, I just use the word visibility because that’s what doc usually in says, but it’s about access the property, so to say, or it being visible to your code. That’s it on visibility but today we can only set one rule so to say, we can only say: this is either public, private, or protected, and in other languages, there are for good reasons, possibilities to have asynchronous visibility. So, or disconnected or whatever you want to call it, between: Please write and read. And then in, with accessors you’ll also have isset() and unset() but that’s really not the topic here at this point.

Derick Rethans 2:56

PHP sort of supports these kind of things, with it’s magic methods, like with __get() and __set(). And then also isset() and unset(). You can sort of implement something like this, of course, in your own implementation, but that’s, of course, ugly, I mean, ugly or, I mean there was no other way for doing it and I remember, you made have a user that in eZ Components that you mentioned earlier. What is the main problem that you’re wanting to solve with what this RFC proposes?

André Rømcke 3:25

the high level use case is in order to let people, somehow, define that their

Truncated by Planet PHP, read more at the original (another 17389 bytes)

PHP 8.0.0 Alpha 3 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the second testing release of PHP 8.0.0, Alpha 3. This continues the PHP 8.0 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.0.0 Alpha 3 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be Beta 1, planned for Aug 06 2020.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

Free book chapter: Key design patterns – Matthias Noback

I wanted to share with you a free chapter from my latest book, “Advanced Web Application Architecture”.
I’ve picked Chapter 11, which gives a compact overview of all the design patterns that are useful for structuring your web application in a way that will (almost) automatically make it independent of surrounding infrastructure, including the web framework you use.

Chapter 11 is the first chapter of Part II of the book. In Part I we’ve been discovering these design patterns by refactoring different areas of a simple web application. Part II provides some higher-level concepts that can help you structure your application. Besides design patterns, it covers architectural layering, and hexagonal architecture (ports & adapters). It also includes a chapter on testing decoupled applications.

If you’re interested in this kind of topic, make sure to get a discounted copy using this link:

Chapter 11: Key design patterns

This chapter covers:

  • A catalog of design patterns
  • Implementation suggestions
  • A high-level design process based on these design patterns

11.1 Framework-inspired structural elements

Every framework comes with its own set of recognized element types.
For instance, Symfony developers learn to create controllers, entities, form types, Twig templates, Yaml configuration files, and so on.
Laravel developers also create controllers, but they need among other things: models, Blade templates, and PHP configuration files.
When you take a look at the directory structure of most web application projects, you’ll immediately notice the framework that’s been used.
Frameworks dictate your project structure.
And frameworks also invade your code.
This all sounds like frameworks are an enemy, instead of the helpful friend they presume to be, but this is a false contradiction.
In infrastructure code, frameworks are your friend.
In core code, they are not.

If frameworks determine the structure of your core code, you’ll end up with:

  • Implicit use cases inside controllers,
  • A domain model that’s coupled to its underlying infrastructure, and in general
  • Code that’s coupled to the framework.

In Part I: Decoupling from infrastructure we’ve already seen many techniques to overcome these problems.
We were able to extract a use case from a controller by modeling it as a framework-independent service.
We extracted an entity from database interaction code.
And we decoupled code from the framework by using dependency injection everywhere, and by passing contextual information as method arguments.

In this chapter we take a closer look at the types of objects that were the result of decoupling from infrastructure.
Knowing more about the typical aspects of these objects will help you use them as building blocks instead of merely the result of refactoring activities.
By using these objects as “primitives” you can implement all of the application’s use cases, without even choosing a framework.
The framework will just be the finishing touch, the bridge between your application’s core and the outside world.

11.2 Entities

The first pattern to cover is the Entity pattern.
In this book the concept of an entity is the same as the concept of an aggregate in Domain-Driven Design literature.
An aggregate is an entity, including any of its child entities, and any of the value objects used inside of it.
In my experience the term “aggregate” leads to a lot of confusion so I decided to use the word “entity” in this book.
We have talked about entity design in Chapter 2: The domain model, and I’ve already mentioned several design rules for it there.
Still, I want this chapter to be a reference guide to the standard design patterns you’ll need in decoupled application development, so I’ll briefly summarize the rules here.
I’ll just declare the rules without defending them in detail.
You can always look up the reasoning in Eric Evans’ “Domain-Driven Design – Tackling complexity in the heart of software”, Addison-Wesley Professional (2003). A quick and accurate primer on the topic is Vaughn Vernon’s article series “Effective Aggregate Design”.

Entities are objects that preserve the state of your application.
They are the only type of objects in your application that have persistent state.
Most of the other objects should be designed to be immutable and stateless.
Being mutable, entities should not be passed to clients that don’t intend to change their state.
When a client

Truncated by Planet PHP, read more at the original (another 46211 bytes)

Byte-sized functional programming: Immutable variables are easier to understand –

Byte-sized functional programming: Immutable variables are easier to understand

An immutable variable is one whose value doesn’t change after it has been first set. PHP doesn’t natively support that, but we can write our classes in such a way to simulate it. For example, rather than this:

class Point
int $x;
int $y;
   public function
__construct(int $x, int $y)
$this->x = $x;
$this->y = $y;
   public function
moveUp(int $by): void
$this->y += $by;

We can write this:

class Point
int $x;
int $y;
   public function
__construct(int $x, int $y)
$this->x = $x;
$this->y = $y;

   public function

moveUp(int $by): Point
$new = clone ($this);
$new->y += $by;

In the second version, once a given `Point` object is created it will never change. We can safely pass it to another function or method and be guaranteed that its value won’t change without us knowing. Instead, any attempt to change it results in a new object, with its own identity, representing the new point in space. (In practice there would be other methods here as well, but we’re focusing on just the mutation part.)

Code that uses immutable variables is easier to think about, because we don’t have to worry about “does passing this object to this function change it?” We know it doesn’t. Once we know something about an object we can guarantee that fact doesn’t change. That can make a lot of subtle bugs impossible, which means we don’t have to spend time looking for or correcting them.

Want to know more about functional programming and PHP? Read the whole book on the topic: Thinking Functionally in PHP.

Thinking Functionally in PHP

21 July 2020 – 7:30am

Advice for new speakers –

Advice for new speakers

Submitted by Larry on 18 July 2020 – 5:18pm

Someone messaged me recently to say he had just been selected for his first-ever conference talk, and since the talks of mine he’d seen in the past were so inspiring he wanted to know if I had any advice for new speakers. Since flattery will often get you somewhere, I offered the following advice. I figure it’s generic enough that I should share it more widely. 🙂

Continue reading this post on PeakD.