Detect whether or not an id3v1 tag exists
Michael Pyne
mpyne at kde.org
Sun Dec 12 05:22:07 CET 2010
On Friday, December 10, 2010 13:59:00 Joel Verhagen wrote:
> Jim,
>
> I poked around the SVN repo for a couple of minutes and found that
> Wheeler added the two lines on a commit at 12:46:13 AM, Thursday,
> January 31, 2008. He doesn't comment to why he add's those specific
> lines, except his in-code comment "Make sure that we have our default
> tag types available.".
>
> It's running just fine for me also with those two lines commented out.
> I'm thinking this is a bug. Maybe he left those lines there on
> accident. Is there a way to suggest this change to the official
> repository?
I'm too busy to dig through the code myself, but a commit of that style would
seem to be trying to ensure that the side effects of running those two
functions (presumably a check of id3v1 and id3v2 tags?) actually occurs.
If the *only* side effect of running that code was to create those tags on
disk it might make sense to get rid of, but I suspect it's more likely that
this is closer to something like the "null object" pattern, where a null
pointer is avoided by simply ensuring that a valid (but effectively null)
object is created.
Another way to go might be to simply ensure that null tags do not get written
back to disk in the output file.
Regards,
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20101211/88e591e0/attachment.sig
More information about the taglib-devel
mailing list