I'm not Paul, but...
If you have a data storage system using CRAP (Create Read Archive Purge)
instead of CRUD, or EventSourcing, or any other system that needs to
maintain history, then you need stored objects that have identities
(document abc revision 123, for instance) so you can reference them. In
order to maintain history, however, when you load that data into a
classed object you do NOT want that object to be mutable, because there
is, by design, no way to "update" that object in place in storage.
Rather, you'd want to have a special "new object" class that is mutable,
persist that to storage, and then on load of historical data you want a
read-only object to expose to application code. That object will still
have an identity, however.
I'm actually working on such a library on the side right now.
--Larry Garfield
On 11/16/2016 11:57 AM, Silvio Marijić wrote:
@Paul,
I understand that immutable doesn't automatically apply value object. Can
you give us some examples where immutable object should have identity?
Cheers
On Nov 16, 2016 4:48 PM, "Paul Jones" <pmjone...@gmail.com> wrote:
On Nov 16, 2016, at 07:57, Silvio Marijić <marijic.sil...@gmail.com>
wrote:
Hi,
To anyone who is interested in this RFC. What do you think what behavour
we
should have when you try to compare two immutable objects by identity
like
this:
I don't mean to be overly-nitpicky here, but it strikes me that the issue
might not be "immutable object" so much as "value object."
That is, an immutable object (or at least a read-only object) might very
well have an identity. But a *value* object, in addition to read-only or
immutable, would have no identity proper.
Maybe using the alternative term (if it applies) would help to clarify the
situation.
--
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
