Hey, Hmm, this causes some other design issues. We will have a SnakSerializer > which has to take a $dataValueSerializer. Of course we should not specify a > concrete type because of flexibility, but a problem of this solution is > that wrong Serializers that cannot handle DataValues will only throw an > exception at runtime but do not show a warning when "compiling". Do you > have any suggestions how we can avoid those issues? >
Good observation. This, a decrease in type safety, is a typical trade-off one makes when creating boundaries. This means the code constructing a SnakSerializer is responsible for making sure it is feeding in a Serializer implementation that can serialize data values. A small price to pay for the decoupling and flexibility gained. Also note that not a lot of code should be constructing these service objects, and know about the dependencies. In fact, this likely should only be done in one place, which is a factory provided by the library. An example of this can be seen here: https://github.com/wmde/AskSerialization/blob/master/src/Ask/DeserializerFactory.php Another important thing to realize is that if one writes the right component and integration tests, any incorrect wiring up of the serializes will be found. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --
_______________________________________________ Wikidata-tech mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
