Introduce Argument Validation for collections (arrays of single type) about uuid HOT 7 CLOSED

Interesting you mention the Collection class. I'm actually working on a separate library that does what you describe. :-)

https://github.com/ramsey/collection

The problem is that it is a PHP 5.6+ library only. So, if we wanted to use it and make this change, we'd be looking at doing it in a version 4.0 of ramsey/uuid, where we set the lowest PHP version to 5.6.

from uuid.

I think since it would be a breaking change anyway, that would make sense, right?
What prevents that library from working in <5.6?

from uuid.

Nothing right now, I think. It was more a decision to move forward and not support older versions of PHP.

from uuid.

Calling dibs on this one

from uuid.

A quick analysis results in the following data:

• There appear to be 8 occurrences of array being used as a type hint within the src directory.
• 5 of those occurrences expect the $fields variable, an associative array whose structure is documented in the docblock for Ramsey\Uuid\UuidInterface::getFieldsHex()
• 1 is the $components argument in Ramsey\Uuid\Codec\StringCodec::getFields() which does not seem to be documented
• 1 is the $providers argument for the FallbackNodeProvider which is discussed in the begin of this thread. It expects an array of NodeProviderInterface instances.
• the last occurrence is the $timestamp argument for the FixedTimeProvider constructor. The docblock states that it is an array containing two elements: the sec and usec components of a timestamp.

In the cases where an associative array is expected, I would recommend the use of value objects. For instance, the $fields value should be a value object that can ensure that it always contains the required fields. The value object itself is responsible for validation of data, and every method that type hints on that value object can be sure that it is valid.

The FallbackNodeProvider appears to be the only actual collection (of homogeneous elements). We can go two ways: either create a collection class (NodeProviderCollection) that ensures that it only contains elements of type NodeProviderInterface. Or, in the FallbackNodeProvider's constructor, we ensure that the array contains only elements of said type. I recommend the last option. While a collection class is more explicit, it also introduces more boilerplate (and the docblock type hint is probably explicit enough). In either case, we could use Benjamin Eberlei's Assert library to ensure that all elements of the array are of the same type in a clean way (this library adds much more input validation options, by the way). It will throw an InvalidArgumentException if the assertion fails.

from uuid.

I agree with introducing a value object for the $fields and your recommendation for checking the array values in the FallbackNodeProvider.

from uuid.

In the cases where an associative array is expected, I would recommend the use of value objects. For instance, the $fields value should be a value object that can ensure that it always contains the required fields.

In the 4.x branch, the fields are now represented by a value object. See here: https://github.com/ramsey/uuid/blob/4.x/src/Rfc4122/Fields.php

from uuid.