rfc:immutability

PHP RFC: Immutable classes and properties

Introduction

This RFC proposes introduction of immutable classes and properties. Currently the only way of achieving immutability is trough encapsulation. Because of that user-land applications are using third party libraries or resort to custom implementations and still there is no easy enforcement of immutability. Introducing this feature would help bring one unified solution to this problem, and also it would remove unnecessary logic from user-land applications. If those mechanizsm is utilized, developer can be sure that he is programming with no side effects, meaning that state of the object can not be changed with developer beeing unaware of that. This especialy comes hand in hand with concurrency when we can guarantee that threads will always read the same value.

Pros

  1. Immutability guaranteed by language instead of user-land implementation.
  2. Programming with no side effects.
  3. Safe for concurrency.
  4. Value objects, DTO's etc. can be easily created.
  5. Properties can be public which removes need for getters without allowing state modification.
  6. (Please point it out more advantages)

Cons

  1. (Please point it out more disadvantages)

Proposal

Immutable Class

Class defined as immutable will imply immutability across all of it's properties by default. After object is constructor, it is not possible to modify state of object from any scope.

immutable class Email {
  public $email;
 
  public function __construct ($email) {
    $this->email = $email;
  }
}
 
$email = new Email("foo@php.net");
$email->email = "bar@php.net" // Call will result in Fatal Error

Changes to inheritance are made to add constraints when extending a immutable class, child class must also be immutable in order to to preserve immutability across whole object.

immutable class Foo{}
class Bar extends Foo{} // Will result in Fatal Error

Immutable Properties

Classes have ability to enforce immutability to only subset of properties if needed, in that case immutability will be implied only on properties that are delared immutable.

class User {
  private $id;
  public immutable $email;
 
  public function __construct ($id, $email) {
    $this->id = $id;
    $this->email = $email;
  }
}

If immutable property contains object, to preserve immutability, object that is beeing assigned to immutable property must also immutable.

immutable class Email{}
 
class User {
  public immutable $email;
 
  public function __construct (Email $email) {
    $this->email = $email;
  }
}

Resources are not allowed to be assigned to immutable properties because of fact that resources by nature are not immutable.

class File {
  public immutable $handle;
 
  public function __construct ($handle) {
    $this->handle = $handle;
  }
}
 
$file = new File(fopen('file.txt'));

If immutable property of parent class is overridden in child class, it has to be declared as immutable. Since focus of this RFC is on immutable objects, having static properties in immutable classes will result in compile error.

References

Assigning by references to immutable properties will result with error, otherwise object looses controll over properties and immutability can be broken.

immutable class Email {
  public $email;
 
  public function __construct ($email) {
    // validation
 
    $this->email = $email;
  }
}
 
$email = new Email("foo@php.net");
$emailRef = &$email->email;
$emailRef = "bar@php.net" // Call will result in Fatal Error

Examples

Notice in above examples removing getters and setting properties to public is optional. They simply doesn't need to be protected anymore in fact that immutable class objects are deeply frozen with eceptions on write.

Every example shows where internal object state is important. Any references to objects passed into immutable class constructor cannot be references to scalars or may be immutable class instances. That gives high guarantee you will keep internal state unchanged for all the time.


Money

Money Pattern, defined by Martin Fowler and published in Patterns of Enterprise Application Architecture, is a great way to represent value-unit pairs. It is called Money Pattern because it emerged in a financial context.

class Currency {
 
    private $centFactor;
    private $stringRepresentation;
 
    private function __construct(int $centFactor, string $stringRepresentation) {
        $this->centFactor = $centFactor;
        $this->stringRepresentation = $stringRepresentation;
    }
 
    public function getCentFactor() : int {
        return $this->centFactor;
    }
 
    public function getStringRepresentation() : string {
        return $this->stringRepresentation;
    }
 
    public static function USD() : Currency {
        return new self(100, 'USD');
    }
 
    public static function EUR() : Currency {
        return new self(100, 'EUR');
    }
}
 
class Money {
 
    private $amount;
    private $currency;
 
    public function __construct($amount, Currency $currency) {
        $this->amount = $amount;
        $this->currency = $currency;
    }
 
    public function getAmount() : float {
        return $this->amount;
    }
 
    public function getCurrency() : Currency {
        return $this->currency;
    }
 
    public function add(Money $other) : Money {
        $this->ensureSameCurrencyWith($other);
        return new Money($this->amount + $other->getAmount(), $this->currency);
    }
 
    public function subtract(Money $other) {
        $this->ensureSameCurrencyWith($other);
        return new Money($this->amount - $other->getAmount(), $this->currency);
    }
 
    public function multiplyBy($multiplier, $roundMethod = PHP_ROUND_HALF_UP) {
        $product = round($this->amount * $multiplier, 0, $roundMethod);
        return new Money($product, $this->currency);
    }
 
    private function ensureSameCurrencyWith(Money $other) {
        if ($this->currency != $other->getCurrency()) {
            throw new \Exception("Both Moneys must be of same currency");
        }
    }
}
 
$oneThousand = new Money(1000, Currency::USD());

After refactoring classes to immutable this example will look like this:

immutable class Currency {
 
    /** @var int */
    public $centFactor;
    /** @var string */
    public $stringRepresentation;
 
    private function __construct(int $centFactor, string $stringRepresentation) {
        $this->centFactor = $centFactor;
        $this->stringRepresentation = $stringRepresentation;
    }
 
    public static function USD() : Currency {
        return new self(100, 'USD');
    }
 
    public static function EUR() : Currency {
        return new self(100, 'EUR');
    }
}
 
immutable class Money {
 
    /** @var float */
    public $amount;
    /** @var Currency */
    public $currency;
 
    public function __construct(float $amount, Currency $currency) {
        $this->amount = $amount;
        $this->currency = $currency;
    }
 
    public function add(Money $other) : Money {
        $this->ensureSameCurrencyWith($other);
        return new Money($this->amount + $other->amount, $this->currency);
    }
 
    public function subtract(Money $other) {
        $this->ensureSameCurrencyWith($other);
        return new Money($this->amount - $other->amount, $this->currency);
    }
 
    public function multiplyBy($multiplier, $roundMethod = PHP_ROUND_HALF_UP) {
        $product = round($this->amount * $multiplier, 0, $roundMethod);
        return new Money($product, $this->currency);
    }
 
    private function ensureSameCurrencyWith(Money $other) {
        if ($this->currency != $other->currency) {
            throw new \Exception("Both Moneys must be of same currency");
        }
    }
}
 
$oneThousand = new Money(1000, Currency::USD());

There is no need for getters because internally immutable object if deeply frozen and none of his properties cannot be written anymore. All properties accepts scalar values or objects which implements immutable classes so there is high guarantee such Money object will keep his internal state untouched.

Backward Incompatible Changes

No backward incompatible changes.

Proposed PHP Version(s)

- PHP 7.2

RFC Impact

To SAPIs

No SAPI impact.

To Existing Extensions

- Reflection is patched.

To Opcache

New Constants

No new constants.

php.ini Defaults

No changes for INI values.

Open Issues

No open issues.

Unaffected PHP Functionality

Future Scope

Proposed Voting Choices

Proposals require 2/3 majority

Patches and Tests

Implementation

After the project is implemented, this section should contain

  1. the version(s) it was merged to
  2. a link to the git commit(s)
  3. a link to the PHP manual entry for the feature

References

Rejected Features

- Immutable interfaces

rfc/immutability.txt · Last modified: 2016/12/02 15:54 by marijic.silvio