Time to take a shot again at the problem described in #4. The requirements have changed, and the goals became clearer.

• The PSR-7 standard provides a means of retrieving values by key, and is being used extensively in both Dhii and RebelCode codebases.
• This standard has been segregated further in a Dhii implementation - specifically separating has() into a new interface HasCapableInterface.
• We have a lot more data about the usage of such interfaces, and their forward compatibility.
• There hasn't yet been a case where we absolutely needed to mutate an object.
• Looks like utility methods such as intersect() (which could compute a mapping of values/keys that are similar between two collections) is not the concern of the collection itself.

This time, interfaces will look like this:

• Meaningful and concise names.
• No mutators.
• Only the bare minimum.

The Problem

Issue #4 mentions multiple subtypes of collections, which are not inter-compatible, but are all compatible with collections themselves. One such subtype should be the Set, which represents an un-ordered key-less collection of unique items.

Suggested Solution

Create SetInterface, exposing all functionality of a set.

There's no interface that would allow to remove an item from a set.

With the dhii/data-container-interface repo deprecated, parties still need interoperability with regard to containers. This appears to fit rather well with the concept of collections, which includes maps, which are inherently containers.

Add the missing interfaces.

The Problem

Interfaces are currently quite monolithic. For many purposes, a collection that can have items added and removed is suitable. But there are cases where a read-only, or a write-only collection is necessary. Or one that can have items added and accessed, but not removed.

Suggested Solution

Break interfaces into multiple smaller interfaces. This should be done with the following considerations in mind:

• There can be different kinds of collections, such as sets, lists, or maps.
• All specialized interfaces of each type must extend a base interface of that type, e.g. ReadableMapInterface extends BaseMapInterface.
• Base interfaces of all types must extend a single base interface, e.g. BaseMapInterface extends BaseCollectionInterface.
• Where possible, specialized interfaces of each type should extend a generic collection interface with a similar specialization, e.g. WritableMapInterface extends WritableCollectionInterface

This way, a very large level of generalization and specialization can be achieved, because the consumer can implement any set of interfaces to expose only the functionality that they wish, and their consumers can depend on only that also.
Additionally, "composite" interfaces can be created to help consumers overcome the problem of not being able to typehint more than one type for the same parameter.

Add a MapFactoryInterface. It should extend ContainerFactoryInterface and IteratorFactoryInterface. This could be problematic, because the config key that stores the items must also be the same for LSP.

• The API has changed also completely, which must be followed by an increase in the minor version number.
• The readme appears to have a broken link.

It's useful to be able to write items to a set.

Extend set interface with method add().

The Problem

In php-fig/container@6c2bc7f (see comments), BC is broken, and parameters now require typehints. On top of that, the min PHP version is also increased. Furthermore, there will likely be other BC-breaking changes on the master branch, which will break this package.

Suggested Solution

Add a stability flag to psr/container dep, e.g. ^1.0@stable. This will allow installation of only released versions. Hopefully, in the future BC-breaking releases the major version wil be increased...

PHP 5 is just too much trouble. Discontinue support, upgrade the environment, add features where necessary for clarity.

AddCapableInterface#add() does not accept an item. This is clearly a mistake.