Download the PHP package matthiasnoback/convenient-immutability without Composer
On this page you can find all versions of the php package matthiasnoback/convenient-immutability. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download matthiasnoback/convenient-immutability
More information about matthiasnoback/convenient-immutability
Files in matthiasnoback/convenient-immutability
Package convenient-immutability
Short Description Make objects initially inconsistent, yet eventually immutable
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package convenient-immutability
Convenient immutability for (some) PHP objects
Warning: I didn't use this library "in the wild" - please let me know if it works in your situation
Installation
Just run:
composer require matthiasnoback/convenient-immutabilityIntroduction
I've often encountered the following situation (in particular when working with command objects).
- I start with a simple object (in fact, a DTO), with just some public properties.
- The Symfony Form component copies some values into the object's properties.
- I copy some extra data into the object (like a generated UUID).
- I then use that object as a command or query message, handing it over to some inner layer of my application.
In other words, I have a class that looks like this:
And use it like this:
Then I want it to be impossible to change any field on the (command) object, making it effectively immutable.
The ConvenientImmutability\Immutable trait solves this problem. When your class uses this trait, it:
- Allows form components and the likes to put anything in your object in any particular order they like.
- Allows you to get the data from it by simply accessing its (public) variables.
- Doesn't allow anyone to overwrite previously set data.
Why would you do this?
- To feel less insecure about using public properties for your desirably immutable objects.
- To prevent accidental writes to objects you assumed were immutable.
What's the problem with this approach?
- Your objects may be immutable...
- but they can still exist in an inconsistent state.
Is this bad? I don't think so. As long as you validate the objects (e.g. using the Symfony Validator) and then throw them into your domain layer, which contains the actual safeguards against inconsistent state.
(You can also just use public properties and treat them as "set once, never again" in other parts of your application.)
License
The MIT License (MIT). Please see License File for more information.
