When using a DateTimeInterface property we get:

Cannot convert property dateTimeProperty to its native counterpart. Missing to{nativeType}() method in the type class DateTimeInterface.

Hi, for an old API, I need to send and retrieve data by SOAP.

And I want to retrieve my data in an Immutable record.
It's possible via https://www.php.net/manual/en/soapclient.soapcall.php

$decoded = $this->client->__soapCall($method, $arguments)

Via this call the decoded variable contains my immutable record filled with data (It can magically be filled by the soap extension I think), But it hasn't been created by the fromArray method, so no propTypeMap is set, and this will cause some troubles if the toArray function will be called.

There are some solutions:

• Create the immutable record for the response before the request with some data, so the propTypeMap is set. But I think, this is a bit overkill.

• Check if the propTypeMap is set in the toArray function. But this is not necessary for all immutable records that are generated with the fromArray (and not with some magical soap shit)
  So I don't prefer that either.

• Make the buildPropTypeMap static function public. I think this is the best solution. So I could first build that propTypeMap before doing the request.

What do you think?

If we have come to a solution, I will make a Merge request.

Thx in advance,
Arne

And btw, I have never mentioned it before: but thx for the great event-engine libraries! They are just awesome!

https://www.php.net/manual/en/reflectiontype.tostring.php

You can get the name from the https://www.php.net/manual/en/class.reflectionnamedtype.php
But I don't have any idea how to retrieve that object from the ReflectionMethod? Do you guys knows how to solve this problem?

easier to find them when many templates are configured

@arnedesmedt I had to change your PHP 7.4 implementation a bit, due to ReflectionType::__toString() being deprecated. See #6
I also added the exception back. Now it's thrown when the property has no type hint. However, we could also use the old logic (method return type) as a fallback in case no property type hint is given.
This would ease the migration path from 1.x to 2.x because you don't have to change all your ImmutableRecords at once. What do you think? Can you provide a PR for it and maybe also add some test cases?

Port this feature from 1.x branch. See this commit / PR.

With a small change it would be possible to support value objects in fromArray factory method.

This line in ImmutableRecordLogic needs to be changed to:

$recordData[$key] = $this->fromType($this->voTypeToNative($val, $key, $type), $type);

• Check if it works like expected
• Add unit tests for it
• Add doc block comments to fromArray and fromRecordData to explain difference *

*) Difference: fromRecordData avoids mapping values to native data and back to VO. So it is more performant. On the other hand, fromArray can be used as a universal factory, which makes handling much simpler.

Instead of checking the type of a value to determine the method call for the correct value object method e.g. fromInt(), fromString() ... we should create a new immutable record trait which only relies on the methods fromNative() and toNative(). This would also reduce the complexity of the trait and increases the performance as well.

For example these methods are not needed anymore.