Really immutable collections

[golaod]

You can read in the documentation:

In general, collections are immutable, meaning every Collection method returns "an entirely" new Collection instance.

But that statemen is not true, because default collection implements \ArrayAccess interface. How about creating AbstractCollection (or trait) that holds most of the logic and have 2 child classes to represent mutable and immutable collections. For backward compatibility the name for mutable collection would stay the same and it would implement \ArrayAccess whereas ImmutableCollection would have add/remove would simply use merge/except under the hood.

[henzeb]

Collection already implements EnumeratesValues. I suggest 2 simple classes: ImmutableCollection and LazyImmutableCollection. the add/remove methods would do merge/except, and the magic offsetSet /offsetUnset methods would throw exceptions.

you could easily do that yourself by the way.

[golaod]

That's not clean and that's why I proposed to move most of the code to AbstractCollection or Trait, so that it can be properly reused in Collection and ImmutableCollection.

[henzeb]

Why is that not clean?

most of the code is already in trait EnumeratesValues, so moving it there would be the same as AbstractCollection

[golaod]

It's not clean to throw exceptions, because given class doesn't implement them. If it doesn't then it shouldn't be part of the parent then. Proper abstraction doesn't require to throw exception about invalid operations. I understand that there might be cases where it's true, but probably even those can be replaced with other design pattern like visitor.

The collection class literally what it should add to basic logic is the data access and any other method that is actually mutating items, whereas abstract would hold everything else that can be shared between Collection and ImmutableCollection. You prefer trait, fine but it still better to add methods than to throw exception cause you don't want them in your class.

[henzeb]

I still prefer ImmutableCollection extends Collection rather than two different objects that can't be used without defining union types.

Returning a new instance like most methods do already should be a logical choice then...

[golaod]

But I proposed AbstractCollection that would hold logic from both. You can have interface that would also help you avoid union types. It's not like that change is a bc breaker because Collection's API and logic inside too. I am simply still in favour of addition not exclusion (with exceptions as showstoppers)