Support "album artist" and "artist sort" in TagLib::Tag interface?

[Ralf Engels]

Hi Jason,
I also thought about that and it would be the way I had implemented it
in the first place.

On the other hand the methods also have benefits.

1. faster.
After all you just need a lookup in the method table and then call the
pointer

2. easy
everybody understands class methods

3. different result types are easy to handle
After all some meta information consists of number (e.g. track number),
binaries (cover image) or even something else.
You will need an overload orgy of getField methods.


My proposal:
for now let's stay with the methods but at least implement some dummy
functions in TagLib::Tag.

BR;
Ralf

On Fri, 2009-01-09 at 15:18 -0500, Jason Voegele wrote:
> On Friday 09 January 2009 09:28:55 am Ralf Engels wrote:
> > I would propose that TagLib::Tag implements a dummy function for this
> > meta informations.
> > Then we would be free to add more without further problems.
> > And you could add your album artists.
> 
> I rather like the idea of a generic "catch all" function that could handle 
> arbitrary tags.  This would allow for adding new tags without breaking the 
> API.  Maybe something like the following set of functions, similar to what is 
> already present in the XiphComment class?
> 
> void 	addField (const String &key, const String &value, bool replace=true);
> void 	removeField (const String &key, const String &value=String::null);
> bool 	contains (const String &key) const;
> 
> And possibly a "supports field" kind of function too?
> 
> bool supportsField(const String &key) const;
> 
> XiphComment and APE::Tag would, of course, always return true for any 
> supportsField(...) call.
> 
> I think something like the above would allow for arbitrary extension of the 
> set of tags supported by the abstract API, and would allow individual Tag 
> implementations to decide how to handle the various tags.  For instance, ID3v2 
> could map addField("ARTISTSORT") to the TSOP tag, etc.
> 
> Any other arguments for or against adding generic tag handling such as 
> described above?
>