As far as I can tell, currently the only branch in udump() that allows serialization of custom types goes through TaggedElement. One must subclass this and implement __str__(). IMO this is problematic for two reasons:
- One may not control the class definition at all so that subclassing is not an option.
- Using
__str__ for EDN serialization might be undesirable. Very often one wants simpler representations for debugging from this method.
- It is not always the case that a custom type must be tagged. One can of course just not return any, but that makes the semantics of
TaggedElement confusing.
I think all of these can be overcome by allowing registering custom handlers for arbitrary types, exactly in the same manner that @tag does. These would be based on type instead of string. One could add some syntactic sugar with a decorator as well.
Or is there some other way I missed?
As far as I can tell, currently the only branch in
udump()that allows serialization of custom types goes throughTaggedElement. One must subclass this and implement__str__(). IMO this is problematic for two reasons:__str__for EDN serialization might be undesirable. Very often one wants simpler representations for debugging from this method.TaggedElementconfusing.I think all of these can be overcome by allowing registering custom handlers for arbitrary types, exactly in the same manner that
@tagdoes. These would be based on type instead of string. One could add some syntactic sugar with a decorator as well.Or is there some other way I missed?