You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to propose for us to pass s::CommonSerialization to all usage of lower. This is so our custom serialization can also dispatch on the catch-all lower(x).
function lower(s::CS, a)
if nfields(a) > 0
JSON.Writer.CompositeTypeWrapper(a)
else
error("Cannot serialize type $(typeof(a))")
end
end
Context
I am trying to use JSON.jl to create a JSON logger, and I am met with the problem that modules and no-field objects (especially Ptr{Nothing} cannot be logged. This resulted in a fallback to the console logger. Because our office enforce standardization of all logs in JSON format, these console logs get ignored, and so we are not alerted by errors!
I started out by defining lower(::Ptr{Nothing}), but this doesn't solve the bigger picture problem: There might one day be error logs that is not captured as it is not in JSON.
To resolve this, I could quite easily subtype CommonSerialization as the behavior is mainly identical. I just need something like:
function lower(a)
if nfields(a) > 0
JSON.Writer.CompositeTypeWrapper(a)
else
sprint(show, a)
end
end
But this is type piracy and resulted in a nasty warning everything we run our code, not a good habit imo. The way I ended up doing it without type piracy warning needed me to duplicate most of lower and show_json within my package.
If lower takes in the serialization and show_json calls it as such, then I can define my own serialization S and have
function lower(s::S, a)
if nfields(a) > 0
JSON.Writer.CompositeTypeWrapper(a)
else
sprint(show, a)
end
end
I think this is aligned with the rationale of creating the serialization type in the first place.
additional benefit
The code currently need a hack to handle enum printing as string. This is needed because user cannot define their own lower(x::Enum) without incurring a type piracy warning.
So with this change we can do away with that, and have:
Thanks, @fredrikekre for the suggestion! 🙏 I had some issue with JSON3.jl's pretty-printing sometime back, so we haven't considered moving to it. I would be interested to give it a good look again when there's ROI, e.g. for the next project, or if our current JSON logger is proven inadequate.
I would like to propose for us to pass
s::CommonSerialization
to all usage oflower
. This is so our custom serialization can also dispatch on the catch-alllower(x)
.For example, the catch-all
lower
will become:Context
I am trying to use JSON.jl to create a JSON logger, and I am met with the problem that modules and no-field objects (especially
Ptr{Nothing}
cannot be logged. This resulted in a fallback to the console logger. Because our office enforce standardization of all logs in JSON format, these console logs get ignored, and so we are not alerted by errors!I started out by defining
lower(::Ptr{Nothing})
, but this doesn't solve the bigger picture problem: There might one day be error logs that is not captured as it is not in JSON.To resolve this, I could quite easily subtype
CommonSerialization
as the behavior is mainly identical. I just need something like:But this is type piracy and resulted in a nasty warning everything we run our code, not a good habit imo. The way I ended up doing it without type piracy warning needed me to duplicate most of
lower
andshow_json
within my package.If
lower
takes in the serialization andshow_json
calls it as such, then I can define my own serializationS
and haveI think this is aligned with the rationale of creating the serialization type in the first place.
additional benefit
The code currently need a hack to handle enum printing as string. This is needed because user cannot define their own
lower(x::Enum)
without incurring a type piracy warning.So with this change we can do away with that, and have:
Then the
show_json
for strings will be clean and efficient, while that for enum fully demonstrate the necessary detour.call to action
Let me know if we like this suggestion? Needs be I can perform the code change, just let me know that we are interested to have this 🙏
The text was updated successfully, but these errors were encountered: