@dantleech Why yes, I do feel your pain on serialization and data validation. :-) Though not using doc block types was a deliberate decision, as I didn't want a doctrine annotations dependency. And because some serialization Metadata goes beyond what phpstan et al usually have.
@Crell I guess it it would rather be the PHPStan docblock parser - I think the Valinor author wrote their own docblock/type parser, which is also what i did for Phpactor, and probably Psalm did the same - somehow seems like duplicated work, but it's fun.
But would love it if we didn't have to support both attributes and annotations, and espcailly if we can avoid duplicating the type info.
@Crell problem with docblock parsers in this context is that most of the library is actually about parsing types 😅 incidentally a middle ground could be to standardise:
#[\Php\Type('Hello<World>')]
Which is basically what JMS serializer supports (although not sure it supports generics). But then as written, it feels bad to import a class/attribute in order to declare a type 🤷 which leaves us with the only sensible solution: having generics support, somehow, in the language
@dantleech I really appreciate that this isn't a list of esoteric gotchas.
We really could use iterator_map/etc functions. The hard part will be convincing people whether to match callback vs iterable first parameter ordering 🙃 or if it should be lazy or immediate. I'd probably go with iterable first and lazy. They'd probably be shortcuts to creating FilterIterator/etc instances.
Add comment