Add support for inlining struct fields.

[rjeczalik]

msgpack encoder differ in behaviour from the json one - the latter inlines
fields of an embedded struct as they were part of the parent struct.

While we can't change the behaviour due to compatibility reasons we can
introduce inline opt, which will make the encoding similar in
behaviour to the json one.

/cc @vmihailenco Please take a look.

[vmihailenco]

Looks solid, thanks. I had something similar before, but it caused #20 and was reverted rjeczalik@f2a814a. I still have to think about implications.

[vmihailenco]

Probably inline -> embed to match Go naming of the concept?

[rjeczalik]

Indeed embed would fit better, however there was already precedence and inline shows up in couple of places:

• proposed inline opt for encoding/json (proposal: encoding/json: add "inline" struct tag golang/go#6213)
• existing inline opt in gopkg.in/yaml.v2 (https://godoc.org/gopkg.in/yaml.v2#Marshal)

So I think it'd be better to stick with inline.

[vmihailenco]

Can you please add following test case:

type CustomTime struct {
    time.Time `msgpack:,inline`
}

What is the expected behaviour in such case?

[rjeczalik]

@vmihailenco Rebased with master and added a test-case for CustomTime. Please take a look.

What is the expected behaviour in such case?

I think the simplest rule here would be: if a struct has no fields to inline it'll be encoded/decode as a whole.

In particular marshalling:

type CustomTime struct {
    time.Time
}

and

type CustomTime struct {
    time.Time `msgpack:",inline"`
}

will give the same results. The same behaviour is in gopkg.in/yaml.v2, which has the inline opt.

[vmihailenco]

I find this block a bit confusing to understand. Probably:

inlinedFields := getFields(ftyp)
if len(inlinedFields) > 0 {
    inlineFields(fs, inlinedFields)
    continue
}

What do you think?

[vmihailenco]

What about inlining struct that implements CustomEncoder? Looks like in this case EncodeMsgpack(*Encoder) error method will not be called... I will try to read golang/go#6213 tomorrow to get an idea about existing design in other packages.

[rjeczalik]

What about inlining struct that implements CustomEncoder?

Yup, sorry, I did not take custom serialisation into account in my initial implementation - I reworked this in my latest commit, which makes inline opt being ignored when a struct implements either CustomEncoder, CustomDecoder or both.

The other option instead of ignoring would be to firstly encode the field with custom encoder or globally registered one and then inline all fields of such struct. The implementation would be a bit more complex, so I think we could defer it to a point where such use-case would be needed and right now live with simpler implementation.

@vmihailenco What do you think?

[vmihailenco]

Actually I think inline tag should has higher priority than CustomEncoder (it seem to be more specific to me). What do you think? I will make appropriate change myself, just want to make sure will not break your code.

[rjeczalik]

@vmihailenco Sure, it's fine by me.

[vmihailenco]

Thanks. I will change it in separate PR.