proposal: encoding: add mechanism to let users control which xml/json fields are omitted at runtime?

[amezghal]

We have the method MarshalJSON() which we can add to our objects in order to customise the serialisation, but there is no why to decide dynamically if we should omit.

How about adding IsValid as another method and lets have more control on the serialisation output,

People are trying to invent non-intuitive solutions like convert struct to map in order to counter this.

same goes for xml marshaler

[mvdan]

Can you elaborate what you mean by "if we should omit"?

Also note that there already is a json.Valid function. The method name IsValid would be confusing to the user, unless the two somehow served the same purpose.

[amezghal]

I mean for struct types, we have the ability to decide how to encode them, using MarshalJSON

suppose i have a type MyType

type MyType struct{
 value string
}

func (mt MyType) MarshalJSON() ([]byte, error) {
	return json.Marshal(d.value + " this is my type")
}

but for example suppose that i want to ignore this field if the value of MyType.value is ""
then i can't

i cannot omit a struct because go cannot decide if a struct is empty,

What we need is a method to implement which tells go if this struct is empty and ignore it

[mvdan]

So what you're asking for is a way to customize the existing omitempty. Certainly seems feasible. This should be a fully fledged proposal, though - see https://github.com/golang/proposal.

Without a proposal and all the details, this particular issue is likely to get closed. Non-trivial changes to the standard library need good reason to be made, so you have to make a compelling argument for them with any evidence you can get your hands on.

[amezghal]

Yes i agree it's a proposal and not an issue,

I will try write the proposal and post it in the given link

Thks

[ericlagergren]

I think there’s already an issue created so that fields will be omitted if custom JSON marshalers return (nil, nil) and omitempty is toggled. Although, I may be misremembering the exact issue.

[mvdan]

@ericlagergren after a bit of googling, I think that might be #4554. An IsZero was discussed there, but the issue was closed automatically after years of inactivity.

[ericlagergren]

There are several issues on this topic and that’s one of them, yeah. If you search for ‘omitempty’ there’s a bunch of them.

…

On Jan 2, 2018, at 10:15 AM, Daniel Martí ***@***.***> wrote: @ericlagergren after a bit of googling, I think that might be #4554. An IsZero was discussed there, but the issue was closed automatically after years of inactivity. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ericlagergren]

• proposal: encoding/json: add omitnil option #22480 (similar)
• proposal: encoding/json, encoding/xml: support zero values of structs with omitempty #11939 (omitempty for zero values of structs)

Here's the CL I was thinking about: https://go-review.googlesource.com/#/c/23088/

[amezghal]

I know there is several issues related to this topic, and there is no solution as far as i know.

the issue is clear, we can add the attribute "omitempty", but struct fields are never empty.
therefore we cannot omit them,

it is unfortunate that we have this in the standard library

// Marshaler is the interface implemented by types that
// can marshal themselves into valid JSON.
type Marshaler interface {
	MarshalJSON() ([]byte, error)
}

we can customise the encoding,
but we dont have a method that go will call on struct field to know if the struct is empty or not.

[rsc]

The encoding/json and encoding/xml packages cannot be all things to all people. If you need custom functionality, please feel free to copy them and modify to suit. We already have compile-time control of which fields are encoded. I don't believe we are going to add run-time control as well.

Note that for any field you can change type T to *T and mark it omitempty and then at run-time choose whether to put a nil or an allocated value there. So in some sense they already support what you're asking for.