Update Messages property of the DBC class to Dictionary

[hakwes]

I would like to see the Messages property of the DBC class to be set as a Dictionary to improve lookup.
Another option would be to add a Get method that would use an internal dictionary.
Another suggestions is to add the ValueTable as a dictionary as a complement to the string. That would simplify mapping values to descriptions.

[EFeru]

Sounds interesting. I din't use Dictionary in C# yet, so if you are willing to help I would be more than happy

[taylorjdlee]

I guess this also somewhat ties into issue #15 making message a dictionary would help in solving this issue as well.

[hakwes]

@EFeru For the messages and the nodes you can just change Dbc properties
public IEnumerable<Node> Nodes {get;} public IEnumerable<Message> Messages {get;}

to Dictionaries since the builder already uses a Dictionary to populate them.
That would be a breaking change though. Hence, you might opt for adding a Get method instead.

For the ValueTable lookup for a signal I've made a workaround in https://github.com/hakwes/DbcParser/blob/currentinternalrelease/DbcParserLib/DbcBuilder.cs#:~:text=%7D-,public%20void%20LinkTableValuesToSignal(uint%20messageId%2C%20string%20signalName%2C%20string,%7D,-private%20bool%20CheckExtID

This fix also solves #13 . I attempted to put that in the ValueTableLineParser but it broke to many tests so i opted for the quickfix above.

[EFeru]

@hakwes Are you willing to support on converting to Dictionary? Especially the Value Tables would be really nice to have them as Dictionary.
I can help you updating the Tests when you have the PR ready.
For now I did a quick fix on Value table because it could not parse properly the spaces see #13 .

[hakwes]

Sure, I'll have a go at it @EFeru

[Adhara3]

Hi,

Why I would not change Node and Message container type to IDictionary

• The c# language provides easy ways to make a list a dictionary using what the user likes as a key.
• forcing a unique key would not work with the composite dbc as in Support for multiple .dbc files #20 because multiple files may contain the same ID.
• the keys we use during parsing depend on how the file links lines, which may not be what the user expects. It is dangerous to expose and internal choice outside, that would make things impossible to change

I think the goal of this library is to parse a text file and put stuff into usable objects. Keep it simple.
If you need extra features do not force them into the parsing process, instead let's add validators or helpers around the parsed objects to provide the requested functionalities.
Indexing is useful but has nothing to do with parsing strictly speaking. It has more to do with optimization.
So we could provide some helper classes like

public class IndexedDbc
{
  public static IndexedDbc CreateFrom(Dbc dbc)
  {
    // Here we take the dbc and convert structures in an optimal way (i.e. indexing)
  }

  private IndexedDbc()
  {
  }

  public bool TryGetMessage(int id, out Message message)
  {
    // Search by index
  }
}

This has the advantage of extending with usability. Having the TryGet method instead of directly exposing the IDictionary keeps the object read only by design

Why I would, instead

Node name should be unique by dbc spec. Same for message IDs and signal names inside a message. So exposing IDictionary directly makes sense because it somehow reflects the specs.
If in the future we plan to write DBCs starting from objects, then we must allow people to build object so the read only approach (e.g. the TryGet method instead) would not allow this. But write objects may be different ones or we could even build the file using an ad hoc builder class.

As you can see I need to think a bit more about this. We can break the API, but if we do it should be for a bigger plan, not just for a specific need we have today.

My 2 cents
A

[Adhara3]

I guess this also somewhat ties into issue #15 making message a dictionary would help in solving this issue as well.

I fear the two things are unrelated

A

[EFeru]

Hi @Adhara3 , thanks for your detailed answer. Is very good to have both advantages and disadvantages in our overview.

[Adhara3]

So just to recap:

• dictionary vs try get, still under investigation. For proper API the same should apply to Messages (by Id) Nodes (by name) and Signals (by name) in a message especially if we want to reflect the spec
• for ValueTable, yes. It is a string because we left the pure parsed value but should become a dictionary or similar.

Cheers
A

[hakwes]

@Adhara3 I don't really understand your concerns about exposing the Message property as a Dictionary.
Internally, messages are added to a Dictionary first and then the Dictionary is converted to an Array.
A Dbc file can be very, very large and adding an index method where you would parse the file again seems excessive.

The TryGet method is fine but I don't think you need to indexDbc class to implement that.