Allow types to determine how to decode themselves

[pcfreak30]

Hello, I am re-posting this as an issue as it is an active need for me that is forcing me to fork out and apply PR's as patches to move forward.

Reference PR: mitchellh#294

PR Author @mthjs

Kudos.

[sagikazarmark]

@pcfreak30 thanks for reposting the issue!

Looking at the original PR there seem to be some discussion around the details.

While we figure those out, would something like work for you: https://github.com/sagikazarmark/mapstructurex/blob/main/decode_hook_map_decoder.go

It's basically the same thing, implemented as a decode hook. You can tweak it to your own needs (I only needed to decode maps, but you could use it for any values).

[pcfreak30]

@sagikazarmark Don't think so. One of the barriers I was running into is the type test immediately after hook processing tries to parse it.

A use case is taking a string and processing it into a struct. For me that is a case of a UUID, and a word seed that gets converted to a Ed25519 key.

When its processed the mapper shouldn't try to be any more smart about it. See https://github.com/go-viper/mapstructure/blob/main/mapstructure.go#L477 https://github.com/go-viper/mapstructure/blob/main/mapstructure.go#L1292

[pcfreak30]

Ive forked and used a variation of the PR LumeWeb@c63fee0

Using Unmarshaler as the interface name and moved it after hook decode as I agree you should be able to effectively filter the data, for more flexibility.

Though I think it could make sense to use support for Yaml Marshall, text unmarshall etc b/c of the standards already there.

[buzzdan]

any ETA for this one?

[sagikazarmark]

One of the barriers I was running into is the type test immediately after hook processing tries to parse it.

A use case is taking a string and processing it into a struct. For me that is a case of a UUID, and a word seed that gets converted to a Ed25519 key.

Forgive my ignorance, but could you provide a code sample that showcases what the problem is with the current decoder hook behaviour and why the above proposed solution wouldn't work in your case?

Thanks!

[pcfreak30]

One of the barriers I was running into is the type test immediately after hook processing tries to parse it.
A use case is taking a string and processing it into a struct. For me that is a case of a UUID, and a word seed that gets converted to a Ed25519 key.

Forgive my ignorance, but could you provide a code sample that showcases what the problem is with the current decoder hook behaviour and why the above proposed solution wouldn't work in your case?

Thanks!

See https://github.com/LumeWeb/portal/blob/4cef4c5833fefc738f6c6d300da68ef87d6acdd2/config/types/identity.go#L64 and https://github.com/LumeWeb/portal/blob/develop/config/types/uuid.go#L34

Im using a forked version of the library atm for my needs. re-reading my past comment as well, One of the barriers I was running into is the type test immediately after hook processing tries to parse it. was a key issue.

I needed mapstructure to not try to be smart and just let me handle it.

See LumeWeb@c63fee0 to see the changes i made.

[git-hulk]

+1, this would be helpful for customizing struct decode behavior.

[pcfreak30]

@sagikazarmark Hello, have you been able to spend any issue on this issue since august?

Would like to not need to maintain a fork 😅

[sagikazarmark]

#166 should address this