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

Multi-Map Feature #17

Open
vergil-SI opened this issue Jun 10, 2019 · 1 comment
Open

Multi-Map Feature #17

vergil-SI opened this issue Jun 10, 2019 · 1 comment

Comments

@vergil-SI
Copy link

I was wondering if there is any intention/desire to support multiple types of keys for retrieving pgns/spns from the PgnLibrary.

It might be preferable to retrieve SPNs using their SPN number rather than their name. Or PGNs by their name, rather than their PGN number.

Something similar to:
https://docs.rs/multi-map/1.2.0/multi_map/

I have no idea the efficiency/speed consequences of such an action, but was just curious as to your thoughts.

@jmagnuson
Copy link
Owner

I think that's a great idea. With DbcLibrary, I am starting to head down the path of having the rawest representation of a DBC under the hood (at least one that is able to go from file to struct and back), and then get creative with the access via API.

If speed were a concern, I could see storing two ref maps, one keying by number and one by name. The obvious tradeoff would be memory footprint, but perhaps that isn't a concern to most applications. One other caveat is that IIRC according to DBC spec, the only unique identifier is the ID from which PGN is derived. It would be possible to have two SPNs that share the same number or name (which.. kind of makes the current PgnLibrary::get_spn function wrong). So the API would either need to guess about which is intended, or just return a slice and make the user decide.

In any case, I'll look further into options and ergonomics with this feature in mind. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants