Repository navigation
Releases: tuxonice/data-transfer-object
Releases · tuxonice/data-transfer-object
Release list
v1.2.0
fix: Fix invalid code generated for a plain array type (#18) A property declared "type": "array" produced a class that does not parse. Unlike string[] or FooTransfer[], a plain array carries no element type, and three places assumed one was always present: - macros.twig emitted both initialisers for a nullable array, giving `private ?array $body = [] = null;` - class.twig appended an "add" method to every array property, so with no element type or singular it emitted `public function add( $): self` - the @var, @return and @param docblocks rendered the element type unconditionally, giving `array<>` and `array|null<>`, and placed the generic after |null DefinitionProvider now handles a plain array explicitly, documenting it as array<mixed> and leaving the singular unset. The add method is emitted only when a singular exists, and the initialiser is chosen rather than concatenated: null when nullable, [] otherwise. Only definitions that previously produced invalid PHP change. The existing expected-output fixtures are untouched, which is what shows scalars, typed arrays, transfer arrays and namespaced classes still generate byte for byte as before. A plain array may now be nullable. The typed-array restriction is unchanged, since ArrayTypeNullableException still guards types ending in []. Fixtures live in tests/Data/PlainArray so the shared Data set, and the tests asserting against it, stay as they are.