[internal] Proposal: restructuring data structure for more flexibility

[formatc1702]

Currently, the cable dataclass stores the information on how many wires the cable/bundle has inside the wirecount field, but iterating over all the wires happens using the colors List, which is not too elegant, or necessarily intuitive.

For v0.3, perhaps it makes sense to revamp DataClasses.py to more closely and accurately represent the physical makeup of the components. This could [at least partly] address #29, #31 and #56.

Here are some ideas, in no particular order, on how the code could be cleaned up.

• A new wire class that lists the properties (gauge, color, length, etc.) of a single wire within the cable.
• Instead of wire, a name like conductor or similar might allow more future flexibility, to define pneumatic or hydraulic lines in a similar fashion to cables.
• Maybe have separate classes (but related by inheritance) for cables and bundles?
  • A cable could then contain a list of wires/conductors.
  • A bundle could work the same way, but additionally, allow other bundle and cable elements as children. This grouping would allow things like sheathing/heatshrink around multiple elements of the different classes.
  • A cable could also contain a kind of sub-bundles for shielded groups, and maybe twisted pairs.
• A parent cable could have gauge and length properties that all children inherit by default. But child elements (e.g. individual wires) could override the default, thus allowing different gauges within a cable or bundle, for example.
• It would be nice to preserve the current YAML syntax for simple cases when all parameters of the child elements are shared, or assigned in a defined way (e.g. color codes). Only users who need fine grained control would need to modify their source YAML files to take advantage of nesting and custom properties for each child.

A similar thing could be undertaken for the connector type. It might contain a collection of pin elements, each with its own properties and manufacturer info. However, I don't see the same level of benefit here, compared to cables.

This issue is intended as a starting point for discussion, there is no sense in starting to code and submit PRs before a new standard is settled... also, it is not top priority at the moment, just something to keep in mind and to think about a little bit :)

[formatc1702]

Closing, to keep the discussion in #56.

[kvid]

I'm not sure I agree that the scope of this issue is fully within the scope of #56. My impression is that #56 is more a discussion about how to structure wires, bundles, and cables. The scope of this issue also cover the more general structure of any component in the harness.

One suggestion that is developing in my mind, is to create a generic Component dataclass that contains all attributes that are common to all components, and then let Connector, Conductor (or some other generic term that can be cable, wire, bundle, tube, pipe, drag chain, etc.), and Device (or some other generic term that can be a switch, a LED, a resistor, etc.) inherit from Component and add or override what is needed for their purposes. Maybe add some intermediate dataclass(es) in the inheritance structure as well if needed - thinking object oriented.

[formatc1702]

I'm not sure I agree that the scope of this issue is fully within the scope of #56. My impression is that #56 is more a discussion about how to structure wires, bundles, and cables. The scope of this issue also cover the more general structure of any component in the harness.

Your impression is not entirely wrong.
However, both issues deal with inheritance, nesting, and changing the syntax to define components, maybe significantly. Since #56 already has some ideas for the syntax, as well as interesting perspectives from other contributors, whereas this one has been inactive except for one 👍, I decided to shift the focus there. I will copy this issue's original post to the other thread so it is not lost. Feel free to do so with the second half of your comment.