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

Replace fqon_t with more advanced identifier type #107

Open
2 of 4 tasks
heinezen opened this issue Jun 15, 2023 · 4 comments
Open
2 of 4 tasks

Replace fqon_t with more advanced identifier type #107

heinezen opened this issue Jun 15, 2023 · 4 comments
Assignees
Labels
c++ involves C++ code improvement improves existing functionality

Comments

@heinezen
Copy link
Member

heinezen commented Jun 15, 2023

Current object, member or namespace IDs are simple std::string types, e.g. fqon_t or fqnn_t. These are sufficient for addressing nyan objects, but are not suitable for advanced operations like:

  • Rebuilding the directory/file path of an object (e.g. for fetching relative file referenced by the file type)
  • Getting the namespace an object is in
  • Checking if an object is nested
  • Checking if a member ID is prefixed (with inheritance info)

Ideally, we want something that captures all of these features while still being as easy to use as std::string.

A good start would be to have a class that manages the individual parts of an fqon:

struct fqon_t {
  std::vector<std::string> dir_parts;
  std::string file_part;
  std::vector<std::string> obj_parts;
};
@heinezen heinezen added improvement improves existing functionality c++ involves C++ code labels Jun 15, 2023
@heinezen heinezen self-assigned this Jun 15, 2023
@heinezen
Copy link
Member Author

Using nyan::Namespace for that purpose is probably the best idea, since it already has a similar purpose.

@TheJJ
Copy link
Member

TheJJ commented Jun 15, 2023

the current types are very simple but efficient, and this is a tradeoff between just-read operations and modifications/updates. currently the code is optimized for the former :) so if we change this, we have to consider the benefits well.

@heinezen
Copy link
Member Author

@TheJJ My current idea is to extend nyan::Namespace with the individual fqon parts idea from above (fqons are already split there, but not by directory/file/object) plus some additional helper methods and save the namespace for each object in ObjectInfo. Everything else will still use fqon_t internally. This would solve most of the requirements for object types (not for members and namespaces though).

Getting the directory/file paths for objects is the most important issue right now because it is pretty much required for using file member values with relative paths.

@heinezen heinezen mentioned this issue Jun 16, 2023
1 task
@heinezen
Copy link
Member Author

see a88045a for the current implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ involves C++ code improvement improves existing functionality
Projects
None yet
Development

No branches or pull requests

2 participants