Option to read string as []byte about msgp HOT 12 OPEN

In principle, I have no objections.

Since Go doesn't support map[[]byte]interface{}, I can have the map decoder convert bin fields to Go string values on decoding. Would that work for you?

from msgp.

The use case I have is as follows:

type A struct {
    Example []B
}

type B struct {
    Name []byte
}

So I'm not actually referring to a map[[]byte]interface{}

But as I understand things, you expect the map received over MSGPACK to be keyed by a string. In this case, Example would be one such key.

Does that help to clarify?

from msgp.

Yes. I'll look in to having the map keys fall back to bin where str fails.

from msgp.

That would be brilliant. Because then I can definitely use msgp

At the moment I'm hand cranking things using http://godoc.org/github.com/vmihailenco/msgpack which is working well but it feels like something go generate (and hence, msgp) could do better than me.

The aforementioned structure I'm receiving over MSGPACK is in fact the definition of an API. Plan is that once I've decoded the definition, I again use msgp to assist in the creation/generation of an API client (which communicates via MSGPACK). Same situation for the API client however: all strings are in fact sent/received as []byte

I hope that makes some sense...

I'm guessing that "falling back" won't incur any penalty?

from msgp.

Let me know if 18a67e9 fixes your issue. It allows map keys encoded as bin to be cast to strings optimistically.

from msgp.

The performance penalty is one more conditional jump and one extra function call - or, in other words, basically nothing.

from msgp.

Thanks for the quick turnaround.

I'm now getting 'map key not convertible to string'

But it's getting late here so I'll take a look tomorrow if possible.

from msgp.

If you can put together a sample I'm happy to take a look at it.

from msgp.

Thanks - looking a bit further, I think it's my fault right now (need a few well placed msg tags). I should be able to get to the bottom of these later tonight. At which point I'll know if there are any residual problems.

from msgp.

Not finding the spare time I want to look at this!

The issue I've hit with 18a67e9 is that I can't decode what is effectively a map[[]byte]X - I realise I told you earlier this wasn't part of my use case. Apologies for that, I had missed this case.

Should I be able to decode such a map with 18a67e9?

from msgp.

Yes. However, the keys will be cast to strings during decoding, and they
will be re-encoded as str if/when you re-serialize the object.

On Thu, Nov 6, 2014 at 6:20 PM, Paul Jolly [email protected] wrote:

Not finding the spare time I want to look at this!

The issue I've hit with 18a67e9
18a67e9
is that I can't decode what is effectively a map[[]byte]X - I realise I
told you earlier this wasn't part of my use case. Apologies for that, I had
missed this case.

Should I be able to decode such a map with 18a67e9
18a67e9
?

—
Reply to this email directly or view it on GitHub
#27 (comment).

from msgp.

@philhofer just picking up this thread to take some of the noise away from #31

Taking the following example:

type Test struct {
    Map map[string]int
}

If you recall you kindly built into 18a67e9 what I see in ReadMapKey which has the fallback to []byte.

However, looking at the generated code for the above, the reading of a the key for the Map field is simply a ReadString which clearly blows up if it encounters a []byte equivalent.

But I wonder given the work in #31 whether an approach that uses shims is more generic?

from msgp.