Re: [Cellar] ReferenceTimecode tracks in Matroska proposal

2016-01-14 13:50 GMT+01:00 Moritz Bunkus <[email protected]>:
> Hey,
>
>> 2016-01-14 13:38 GMT+01:00 Moritz Bunkus <[email protected]>:
>
>> > Please keep in mind that existing Matroska libraries (not just
>> > libMatroska) name their functions/classes after the elements in the
>> > specs. Renaming the elements in the specs requires either that the the
>> > classes/functions in the libraries be renamed as well (breaking
>> > compilation with each and every program out there) or we'll end up with
>> > a severe discrepancy between the naming in the libraries and the specs
>> > (especially if new elements will be introduced after the renaming with
>> > names that were used before the naming!).
>>
>> The spec file already has a way to override the name of the C++ class
>> when it doesn't match exactly the one displayed in the specs (usually
>> shorter or just to keep backward compatibility). We just need to use
>> this for such elements.
>> Maybe also add some typedefs to have both old and new names.
>
> What I meant:
>
> - Rename e.g. ClusterTimecode to ClusterTimestamp in the specs
> - Leave the class name the same in the library (ClusterTimecode)
> - Then introduce elements in the spec dealing with actual timecodes
>   (e.g. ReferenceTimecode) which would translate into a class name
>   ReferenceTimecode

I see. Such confusion can be easily avoided. We just need to make sure
to provide backward compaibility.

> Now you have the situation that a developer working with such a library
> would have several classes with Timecode in their name and some of
> those would deal with timestamps and others with timecodes. Highly
> confusing to anyone not familiar with our current discussion.

We could include the text from the specdata as a comment for each
class name. That should at least avoid some confustion.

> Also: functions like KaxBlockGroup::GlobalTimecode() – those return
> timestamps. If not returned it would be very, very confusing for new
> users to determine what they actually return, timestamps or timecodes.

These aren't aren't generated IIRC. So we can edit and document that
manually. Providing both might be a good idea for a future transition.

> Kind regards,
> mosu
>
> _______________________________________________
> Cellar mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cellar
>



-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel