At first, I designed converters for being based on the mapping type of an entity property.
(The mapping type is the type used by the ORM. As described by Doctrine documentation "Mapping Types are NOT SQL types and NOT PHP types! They are mapping types between 2 types.")
While I was working on the IntegerConverter, I thought forward to an hypothetical SmallIntConverter (as there is a smallint mapping type in Doctrine). There is no smallint type in PHP but only an integer type. In which way a SmallIntConverter would differ from an IntegerConverter? The difference would be related to the maximum value allowed. But this max value has no meaning outside of the ORM context: it is the maximum value allowed by the persister. And this is not known at the time the conversion is made. Furthermore, we can imagine situations where entities will not be persisted and thus won't have mapping metadata.
The converters must be rewritten to be based on PHP internal types. And the max values must be declared as validation constraints.
At first, I designed converters for being based on the mapping type of an entity property. (The mapping type is the type used by the ORM. As described by Doctrine documentation "Mapping Types are NOT SQL types and NOT PHP types! They are mapping types between 2 types.") While I was working on the
IntegerConverter, I thought forward to an hypotheticalSmallIntConverter(as there is asmallintmapping type in Doctrine). There is nosmallinttype in PHP but only anintegertype. In which way aSmallIntConverterwould differ from anIntegerConverter? The difference would be related to the maximum value allowed. But this max value has no meaning outside of the ORM context: it is the maximum value allowed by the persister. And this is not known at the time the conversion is made. Furthermore, we can imagine situations where entities will not be persisted and thus won't have mapping metadata.The converters must be rewritten to be based on PHP internal types. And the max values must be declared as validation constraints.