Hi dear community! We would like to hear your opinions on an RFC (that is inside the thread) in orde

Valerii Trots

Hi dear community!
We would like to hear your opinions on an RFC (that is inside the thread) in order to understand if it makes sense to invest time into it. Please either put +- as reaction if it's needed or not or comment in the thread.
Thank you for your feedback!

Valerii Trots

RFC: Value objects in Transfers

We had a few important steps last year to make transfers more type-safe, more consistent.
We so far do not yet have value object support built in.

Reasoning
With timezone relevance, we are customers might soon be interested to transport datetime values as such objects, rather than plain strings as it is now.
It also makes display in the correct timezone and localization in the right language/syntax easier, if the VO supports this.

E.g. Cake\Chronos\Date (https://github.com/cakephp/chronos/blob/master/src/Date.php )

We currently use decimal as native type using internal Spryker\DecimalObject\Decimal class.

But we could just as well think about many use cases a VO would be better suited than pure scalar or array values, that then need to be processed by template helpers or custom business logic all over the place for simple operations as well as printing out.

Examples:
*Coordinates
*Enums
*Color, Paint, hex or otherwise
*Money ⚠
*IPAddress/Web/Identity

See for example https://github.com/cultuurnet/valueobjects

Syntax
Always a FQCN string with leading \ to make sure this is not a transfer name:
<field name="lastLogin" type="\Cake\Chronos\Date"/> as immutable datetime VO

Implementation

elseif (!empty($this->_metadata[$field]['isClass']) && !is_object($value)) {
    $value = $this->createWithConstructor($field, $value);
}

So based on the isClass detection and the type being that class, we just need

return new $class($value);

Requirement:

$y = fromArray(toArray($x))
$x === $y

In order for the to array / from array part to work, any VO that cannot use scalar constructor value must implement a FromArrayToArray interface, and the building of the object would then use e.g.

    /**
     * @param array $config
     *
     * @return string|null
     */
    protected function detectSerialize(array $config): ?string 
    {
        $serializable = is_subclass_of($config['type'], FromArrayToArrayInterface::class);
        if ($serializable) {
            return 'FromArrayToArray';
        }

        $jsonSafeToString = is_subclass_of($config['type'], JsonSerializable::class);
        if ($jsonSafeToString) {
            return null;
        }

        if (method_exists($config['type'], 'toArray')) {
            return 'array';
        }

        return null;
    }

For scalar representation we cannot assert an interface and need to trust the value object to handle this properly. This is the responsibility of the dev here to make sure only such VOs are used.
This is especially important with existing VO like the ones linked above, as we cannot easily make them “implement” any such interface. We could only extend on Spryker/Project side and require those wrapper libs to be used. But this often doesn’t work with the VO itself on e.g. cloning returning the vendor instance instead of the wrapper one. So best to not address this and opening up more issues.

BC
no BC issues here, it would fully work and exist beside the current “Transfer” names, as those do not start with FQCN \ string.

UKJND3A3H

Thanks for looking into this area! Have been longing for that for years 🙂

Ahmed Sabaa

If you’re reacting with a yes, it would also be helpful to know what use case you have for such feature 🙂