You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
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.
The text was updated successfully, but these errors were encountered: