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
ItemKey::Unknown has served its purpose, and has had better alternatives for a couple years now. It's been a source of confusion numerous times, and its existence also requires extra verification logic on conversions. I'd like to see it gone.
I envision people taking their Tags, converting them to a concrete format (e.g. VorbisComments), and then adding their custom fields to that. I'd rather not have a way to generically add custom fields, since the mappings for the concrete ItemKey variants are known to be valid, but with Unknown, there's extra verification that needs to be done on conversions that could be skipped if I just get rid of it entirely.
ItemKey supports the keys that the vast majority of users will need, anything else would be niche and require a little extra effort working with the concrete formats.
The text was updated successfully, but these errors were encountered:
ItemKey::Unknown
has served its purpose, and has had better alternatives for a couple years now. It's been a source of confusion numerous times, and its existence also requires extra verification logic on conversions. I'd like to see it gone.Comment taken from #520
ItemKey::Unknown
was kind of a hacky way to retain tags that couldn't be mapped to concreteItemKey
s. There have been alternatives for awhile now though, with SplitTag, MergeTag, andGlobalOptions::preserve_format_specific_items()
(see #302 for more info on that).I envision people taking their
Tag
s, converting them to a concrete format (e.g.VorbisComments
), and then adding their custom fields to that. I'd rather not have a way to generically add custom fields, since the mappings for the concreteItemKey
variants are known to be valid, but withUnknown
, there's extra verification that needs to be done on conversions that could be skipped if I just get rid of it entirely.You'd go from:
to:
ItemKey
supports the keys that the vast majority of users will need, anything else would be niche and require a little extra effort working with the concrete formats.The text was updated successfully, but these errors were encountered: