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

Establishing a single interface in and out of the library (Using Formats for all data input and output) #171

Open
Atahanak opened this issue Sep 24, 2022 · 0 comments
Labels
state: pending Taking action type: feature Brand new functionality, features, workflows, endpoints, etc

Comments

@Atahanak
Copy link
Collaborator

Currently, the preprocessing functions either return a Format * or a CPP native type. Even though it may be relatively easier for the user to get the native types and use them directly, it raises some questions concerning the coherency of the library. The following are some advantages of establishing Format * as the medium of exchange between the user and the library.

  1. Users know what to expect from and what to input to the library.
  2. Utilities like FeatureExtractor and Experiments benefit from this update and can switch to Format * instead of std::any.
  3. Additional information like size etc., is stored in Format * but not native types. This is especially useful if the returned object's size is unknown beforehand.

We already needed and used a similar solution with CUDAArray.

@AmroAlJundi AmroAlJundi added state: pending Taking action type: feature Brand new functionality, features, workflows, endpoints, etc labels Sep 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state: pending Taking action type: feature Brand new functionality, features, workflows, endpoints, etc
Projects
None yet
Development

No branches or pull requests

2 participants