Re: Immutability RFC

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" <pmjones88@gmail.com> wrote:

On Nov 16, 2016, at 07:57, Silvio Marijić <marijic.silvio@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 pmjones88@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