Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

querying valid values for enums #149

Open
mbunkus opened this issue Jan 6, 2024 · 5 comments
Open

querying valid values for enums #149

mbunkus opened this issue Jan 6, 2024 · 5 comments
Labels
abi-break breaks the ABI (e.g. programs linked against the library have to be recompiled) enhancement Semantic Change in the semantic interepretation

Comments

@mbunkus
Copy link
Contributor

mbunkus commented Jan 6, 2024

Looking at #148 which embeds the information about the minimum & maximum version number an element is valid for in libMatroska, I thought about also having the information available which values are valid for the various enums we have in the specs. At the moment we only have C-style enum for them, which means we can use them in the code via their names, but there's no way to have the program query the library if a given value is valid or not.

For example, it would be nice to be able to query libMatroska & ask if the value 1 is valid for the "color primaries" element (it is) or if 14 is (it isn't).

On top of that it would be nice if the library simply provided a list of valid value/description pairs that an application can use for selection or to translate what a given value refers to (think mkvinfo outputting the name of the "color primaries" along with the numeric value).

I'm thinking about two or three functions, the example being for an unsigned integer-based enum:

static bool IsValueInSpecs(uint64_t value);
static std::string GetDescriptionForValueFromSpecs(uint64_t value);
static std::vector<std::pair<uint64_t, std::string>> GetValuesDescriptionsFromSpecs();

I'm trying to avoid the word "valid" here as these functions are all static; they only provide information straight from the specs. Not really happy with the names, though…

@mbunkus mbunkus added enhancement abi-break breaks the ABI (e.g. programs linked against the library have to be recompiled) Semantic Change in the semantic interepretation labels Jan 6, 2024
@robUx4
Copy link
Contributor

robUx4 commented Jan 7, 2024

Sounds good although I don't understand the static part. It seems the values are tied to one element (it is in the XML spec) and so each enum belongs to a particular element (and can be moved there). The enums are generated from the XML so we can do all kind of things here.

@mbunkus
Copy link
Contributor Author

mbunkus commented Jan 7, 2024

I meant "static member functions", not "static global functions", e.g.

class KaxTracktype {
public:
  static bool IsValueInSpecs(uint64_t value);
};

As in… a static function on the respective classes instead of a member function on the instances of the classes.

@mbunkus
Copy link
Contributor Author

mbunkus commented Jan 7, 2024

We might also add

class KaxTrackType {
  bool IsCurrentValueInSpecs() const {
    if (!ValueIsSet())
      return false;
    return IsValueInSpecs(GetValue());
  }
};

as an instance method. The other three functions I mentioned are independent of the instance, though.

@robUx4
Copy link
Contributor

robUx4 commented Jan 7, 2024

Ah yes, that could work, although I would put that in the EbmlCallbacks (which name is not very good) as it holds all the specs data and there's one static instance per class.

@mbunkus
Copy link
Contributor Author

mbunkus commented Jan 7, 2024

Ah, you're right, that would be the logical place to put the static functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abi-break breaks the ABI (e.g. programs linked against the library have to be recompiled) enhancement Semantic Change in the semantic interepretation
Projects
None yet
Development

No branches or pull requests

2 participants