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: https://leanpub.com/web-application-architecture/c/RELEASE_DAY.

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 – larry@garfieldtech.com

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:

<?php
class Point
{
   private
int $x;
   private
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:

<?php
class Point
{
   private
int $x;
   private
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;
       return
$new;
   }
}
?>

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

Larry
21 July 2020 – 7:30am

Advice for new speakers – larry@garfieldtech.com


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.

PHP Internals News: Episode 62: Saner Numeric Strings – Derick Rethans

PHP Internals News: Episode 62: Saner Numeric Strings

In this episode of “PHP Internals News” I talk with George Peter Banyard (Website, Twitter, GitHub, GitLab) about an RFC that he has proposed to make PHP’s numeric string handling less complicated.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

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 62. Today I’m talking with George Peter Banyard about an RFC that he’s proposing called saner numeric strings. Hello George, how are you this morning?

George Peter Banyard 0:36

How are you; I’m doing fine. I’m George Peter Banyard. I work on PHP, and I’m currently employed by The Coding Machine to work on PHP.

Derick Rethans 0:46

I actually think I have a bug swatter from The Coding Machine, which is hilarious. Huh, I can’t show you that okay of course in a podcast and not on TV. But yes, I think I got it in Paris at some point at a conference there, and it’s been happily getting rid of flies in my living room. Anyway, that’s not what we want to talk about here today, we want to talk about the RFC that is made, what is the problem that is RFC is hoping to address?

George Peter Banyard 1:09

PHP has the concept of numeric strings, which are strings which have like integers or floats encoded as a string. Mostly that would arrive when you have like a get request or post request and you take like the value of a form, which would be in a string. Issue is that PHP makes some kind of weird distinctions, and classifies numeric strings in three different categories mainly. So there are purely numeric strings, which are pure integers or pure floats, which can have an optional leading whitespace and no trailing whitespace.

Derick Rethans 1:44

Does that also include like exponential numbers in there?

George Peter Banyard 1:48

Yes. However trailing white spaces are not part of the numeric string specification in the PHP language. To deal with that PHP has a concept of leading numeric strings, which are strings which are numeric but like in the first few bytes, so it can be leading whitespace, integer or float, and then it can be whatever else afterwards, so it can be characters, it can be any white spaces, that will consider as a leading numeric string. The distinction is important because PHP will sometimes only accept pure numeric strings. But in some other place where we’ll accept leading numeric strings. Of casts will accept whatever string possible and will try to coerce it into an integer. In weak mode, if you have a type hint. It will accept leading numeric strings, and it will emit an e_notice that a non well formed string has been encountered. When you use like a purely string string, you’ll get a non numeric string encountered warning. So the main issue with that is that like strings which have a leading whitespace are considered more numeric by PHP than strings with trailing whitespaces. It is a pretty odd distinction to make.

Derick Rethans 3:01

For me to get this right, the numeric string in PHP can have whitespace at the start, and then have numbers. There’s a leading numeric string that can have optional whitespace in front, numbers and digits, and then rubbish. Then there’s a non numeric string which never has any numbers in it.

George Peter Banyard 3:22

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

Byte-sized functional programming: Pure functions make testing easy – larry@garfieldtech.com

Byte-sized functional programming: Pure functions make testing easy

When testing stateful code, you have to first set up all of the explicit and implicit state that a given piece of code depends on. If the object you’re testing has many dependencies that could be complex, or references global variables, or calls many other routines with their own dependencies, you may be looking at a lot of complex setup that makes testing hard to do effectively.

Pure functions greatly reduce that problem.

A pure function is a function that:

  • has no inputs other than those explicitly specified;
  • has no effect on any value other than the value it returns.

That means there is, by definition, only one place to inject dependencies: the call itself. And there’s only one effect to validate: the return value of the function. No need to call a function and check what the effect was on some other value or piece of code: by definition, the only effect is the return value.

If one of the parameters you pass in is itself complex, that may make the test complex. But if the parameter is complex, that can serve as an impetus to simplify it. Rather than passing in an object, for example, just pass in a single function. If that function in practice has more complexity behind it, fine, but it makes passing a mock function trivial. Just… make a new (anonymous) function for the one test.

When your code has fewer sneaky interactions, there’s less effort involved in testing as well as fewer things to test.

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

Thinking Functionally in PHP

Larry
14 July 2020 – 9:28am

PHP Internals News: Episode 61: Stable Sorting – Derick Rethans

PHP Internals News: Episode 61: Stable Sorting

In this episode of “PHP Internals News” I chat with Nikita Popov (Twitter, GitHub, Website) about his Stable Sorting RFC.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:18

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 61. Today I’m talking with Nikita Popov about a rather small RFC that he’s proposing called stable sorting. Hello Nikita, how are you this morning?

Nikita 0:36

Hey, Derick, I’m great. How are you?

Derick Rethans 0:38

Not too bad myself. Let’s jump straight in here. The title of the RFC is stable sorting, what does that mean, what is stable sorting, or what is sorting stability?

Nikita 0:48

Sorting stability refers to the behaviour of the sort when it comes to equal elements. And equal share means that we sort comparison function. For example, the one you pass to usort says the elements are equal, but there is still some way to distinguish them. For example, if you’re sorting some objects, to take the example from the RFC, we have an array with users, and users have an age, and we use usort to only sort the users by age. Then according to the comparison callback all users with the same age are equal. But of course, the user also has other fields on which we can distinguish it. And the question is now in what order will equal elements appear. If we have a stable sort, then they will appear in the order they were originally in. So it’s something not going to change.

Derick Rethans 1:41

And that is not what PHP sorting mechanism currently does?

Nikita 1:44

Right. PHP currently uses an unstable sort, which means that the order is simply unspecified. It will be deterministic. I mean if you take the same input array and sort it, then every time we will get the same result. But there is no well specified order or relative order of elements. There’s just some order. The reason why we have this behaviour is that well there are, I would say, two, the only two sorting algorithms. There is merge sort. Which is a guaranteed n log n sort that the stable, but has the disadvantage that that requires additional memory to perform the merge step. The other side there is a quicksort, which is an average case n log n sorting algorithm and is unstable, but does not require any additional memory. And in practice, everyone uses one of these algorithms, usually with a couple of extensions on sort of merge sort. Nowadays we use timsort, but which is still based on the same underlying principle, and for quicksort, we have sort which is better than quicksort, which tries to avoid some of the bad worst case performance which quicksort can have. PHP currently uses us a quicksort, which means that our sorting results are unstable.

Derick Rethans 3:07

Okay, and this RFC suggesting to change that. How would you do that? How would you modify quicksort to make it stable?

Nikita 3:15

Two ways. One is to just change the sorting algorithm. So as I mentioned, the really popular stable sorting is timsort, which is used by Python by Java and probably lots of other languages at this point. And the other possibility is to stick with an unstable source. So to stick with quicksort, but to artificially enforce that the comparison function does not have, does not report equal elements that a

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