new EnumSet methods

[marc-mabe]

I have a couple of ideas to improve the work with enum sets based on my experiences with it.

Allow to get/set both Little-Endian and Big-Endian bitsets

There are already methods EnumSet::[get/set]Bitset but it only allows Big-Endian where the internally handled bitset is in Little-Endian. This adds unnecessary overhead and reduces the supported set of features.

So I propose to add methods for both versions and deprecate the old ones:

• EnumSet::getBitset() : string
• EnumSet::setBitset(string $bitset)
• EnumSet::getBinaryBitsetLE() : string
• EnumSet::setBinaryBitsetLE(string $bitset)
• EnumSet::getBinaryBitsetBE() : string
• EnumSet::setBinaryBitsetBE(string $bitset)

Add a couple of test methods

• EnumSet::isEqual(EnumSet $other) : bool
• EnumSet::isSubsetOf(EnumSet $other) : bool
• EnumSet::isSupersetOf(EnumSet $other) : bool

Add methods to create another set based on two or more sets

These methods would create a clone of $this and change the bitset to not depend on implementation details of extended classes.

• EnumSet::union(EnumSet ...$others) : EnumSet
• EnumSet::intersect(EnumSet ...$others) : EnumSet
• EnumSet::diff(EnumSet ...$others) : EnumSet

Add methods to convert a set back to a native PHP array

• EnumSet::toArray() : Enum[] ordinal number to enumerator instance
• EnumSet::toValues() : scalar[] ordinal number to enumerator value
• EnumSet::toNames() : string[] ordinal number to enumerator name

Thoughts?
@prolic

[prolic]

Allow to get/set both Little-Endian and Big-Endian bitsets

👍

Add a couple of test methods

👍

Add methods to create another set based on two or more sets

👍

Add methods to convert a set back to a native PHP array

👍

Addtional stuff I would like to suggest:

Make it value objects

The current implementation with EnumSerializableTrait is a little annoying. I currently wrap it therefore and only test by value, like in any other value object implementation, you compare two value objects by comparing their data, not but object identity. This will also remove the need to have singleton implementation, but the singleton is not my main concern. So I would be open to leave singleton or remove singleton behaviour, but comparing by value is more important to me.

PHP 7.1 support

As this would be a new major version, I would suggest working with PHP 7.1 (RC1 is already there) and have proper return types and type hints. Even if you like to support PHP 5.x for a while, this could be two new major releases. Upgrading to the newest PHP 7.1 is highly recommended anyway.

Generally: I really like your new proposals!

[marc-mabe]

Thank you for the quick review. I'm happy you like it :)

Make it value objects

The current implementation with EnumSerializableTrait is a little annoying. I currently wrap it therefore and only test by value, like in any other value object implementation, you compare two value objects by comparing their data, not but object identity. This will also remove the need to have singleton implementation, but the singleton is not my main concern. So I would be open to leave singleton or remove singleton behaviour, but comparing by value is more important to me.

It's implemented as singleton becaus an enumeration can have only a predefined set of values so I can make sure I only have one instance per value. This way every same value results in the the same instance. Additionally there is the merhod Enum::is() to allow to test one enumeration instance to another or to another unspecified value but this is just because the lack of native enumerations in PHP. So in my understanding an enum is already a Value Object. The only exception is serializing because it's impossible to unserialize it into an existing instance --> I can make some tests if/how the method Enum::is() does/can support different instances of the same enumerator possible by serialization.

PS: if you like further discussion please open a new issue and point me to your suggestion.

If you want to discuss EnumSet as value object also please open another issue ;)

PHP 7.1 support

There is only one feature missing I have a pull reaquest already. It's not ready but I know how to solve it and I will finish this if PHP 7.1 has been released. Features like scalar type hints, return type hints or argument unpacking are very nice but are not required for this library - you would work with it exactly the same as before. The only improvement is performance and should also be discussed and benchmarked before in another thread.

[marc-mabe]

closed by #63, #64, #65 and #66