I am working on a 2D CAD program that will be used to display wiring diagrams.
I am trying to decide on a good data structure for wires and cables. (I am a completely self taught coder, and never took a Data Structures or Algorithms class).
Currently I have a WireType struct and a CableType struct (Library Types) that store common properties of each object, such as manufacturer, color, overall structure, etc and then a Wire struct and a Cable struct (Project Types). The Project Type structs are instances of the types represented by the Library Type structs within the program. Each Project Type data stores a string key that refers back to its associated Library Type.
All of this data currently gets read in from TOML files via Serde and stored in a master Library or Project struct.
I just switched to using separate structs to represent the data read in from the TOML files vs the data stored in memory, as there are way more data fields on the in-memory versions. (thanks to an answer on a different question.)
Where I am questioning things, is the nested nature of wires and cables. As an example, see the following image of a cable with 4 cables inside it, each with 3 wires.
In my program, i need to be able to reference each individual core of a cable, so I can link it to specific connection points on other entities.
I have a CableCore enum that can contain either a Wire or a Cable, and each cable can have any number of CableCores. This means that CableCores can be nested until recursion depth is reached...
One core of my question (no pun intended), is should I keep Wires separated out, or just treat them as Cables with 1 core within my internal data structures as I can have different data structures in memory than in the file.
The other core of my question, is how to handle nested cables/cores like the above when I need to have a user refer to a specific core or set of cores in a Project file to define connections between other entities. It would be much easier if I had the user define everything via a GUI and keep track of everything behind the scenes, but I want to have the users define everything in TOML files.
Essentially the workflow for the end user of the software is the following:
Define WireTypes and CableTypes in Library files
Define individual Wires and Cables in Project files
Define the Equipment the wires and cables are connecting to in other Project files
Define the Connections between Equipment using a specific Wire/Cable/Core of a Cable. The connection would include what Equipment is on each end, what ConnectionPoint is in use on each Equipment for each end, and then which Wire/Cable/Core of a Cable is connecting those two Equipment instances.
The last step is the piece I am struggling with the most, as I have no easy way to associate user visible IDs to nested cores within a cable, unless I essentially hard code a specific algorithm which is inflexible.
I have an implementation currently that "Works" TM, but the implementation doesn't feel like I am doing things the correct way, repeating myself a lot and backing myself into corners. It also relies on the users defining the core ids in a very specific way that is inflexible.
I apologize for the wall of text, and thank you to anyone in advance who has suggestions / feedback on this.
This is more of a schema design problem than a Rust problem — you’d have the same problem in your data files in any language, even if the implementation of processing those files looked different.
If I were solving this problem for my own use, I would say that each cable definition in a file should be able to give names or numbers to each of its internal cables or the cables/wires named in those cables — pretty much exactly like how in Rust, a module can choose to pub use (and rename) items from inside its child modules. Thus, for example, a CAT-5 (Ethernet) cable could have wires numbered 1-8 even if it is made up of four twisted-pair sub-cables which each label their wires 1 and 2 or A and B or something, but it could also provide names for the pairs if desired.
Agreed that this is more of a Schema design issue than a rust specific issue. I posted it here, since folks have been helpful in the past, and rust has some quirks with data structure design (self referential structs, ownership, etc).
Do you have any thoughts on how you would implement that specifically?
It depends on what operations the data structure needs to support, and which ones need to be efficient.
But the problem is made much simpler by the fact that you are not, as far as you have said, writing an editor. This means you can — and probably should — build data structures that represent the data loaded from the TOML files in multiple ways.
For example, you might, while reading a cable definition, traverse it recursively and come up with a unique ID for every sub-cable and every wire in the cable, and for each such ID, store a path whose components identify where, in the tree of nested cables, that specific wire or cable can be found. That way, the in-memory representation of Connections only needs to refer to these unique IDs which can be just numbers, which makes things easier and cheaper to work with; the Connection representations never need to care about the structure of cables, just point to “that part”.
If you’re familiar with database servers, think of this as indexing — you can have as many indexes as you need for different kinds of queries.
For automatic numbering, I think labeling each bundle of wires with a letter and each conductor with a number might be worthwhile. For CAT-5 cable, that would look like four pairs labeled A-D (or A-E if you count the cable as a whole), with eight conductors labeled 1-8.
Agreed. There is no need to specifically represent exactly what is in the TOML files on the display. I am thinking of this more like a Markdown or LaTeX renderer than an actual CAD program. I do want to give users the flexibility to move objects around on screen once the objects are rendered, but the on disk data structure doesn't need to include that data directly.
I have been trying to implement something similar, but I am running into a problem, where I need to either generate those IDs in a predictable and documentable fashion, so that someone can define which core goes which in the TOML file, or map from predictable IDs to internal IDs which just seems to add its own layer of headaches.
Right now, this is how I am defining a connection in the TOML file, where end1 and end2 are the string key in a map of Equipment, directly read in from the TOML file, and connection is an inline table like { Cable = { cable_id = PLACEHOLDER, core_id = PLACEHOLDER } } where the ID of the cable is also a string key in the map of Cables read in from the TOML file.
# This hasn't been fully vetted yet and is more an example of what I am trying to do.
[cables]
[cables.cable1]
cable_type = "belden_638AFJ"
length = {value = [20, 1], original_unit = "meter"}
[equipment]
[equipment.switch1]
equipment_type = "spst_toggle_switch"
identifier = "switch1"
[equipment.switch2]
equipment_type = "spst_toggle_switch"
identifier = "switch2"
[[connections]]
end1 = {Equipment = {equipment_id = "switch2", connection_point_id = "right"}}
end2 = {Equipment = {equipment_id = "switch1", connection_point_id = "left"}}
# This core_id is what I am trying to find a good solution for. This is just an idea.
connection = {Cable = {cable_id = "cable1", core_id = "card_reader.card_reader_3_pair_inner.black"}}
[[connections]]
end1 = {Equipment = {equipment_id = "switch2", connection_point_id = "left"}}
end2 = {Equipment = {equipment_id = "switch1", connection_point_id = "right"}}
# This core_id is what I am trying to find a good solution for. This is just an idea.
connection = {Cable = {cable_id = "cable1", core_id = "card_reader.card_reader_3_pair_inner.red"}}
Sure, you should definitely allow for customizing the labels. But unless you force the user to label each core themselves, you'll need to do something automatically. Your options are to label sequentially, with no regard to nesting; label with full nesting (e.g. 0.2.4); or something in between (like my suggestion, only differentiating between the bottom layer (conductors) and the upper layers). There's no magic algorithm to assign semantically meaningful names to arbitrary bunches of wires.
I agree that I need an automatic mechanism for core identification (kinda what I am asking for advice about in the OP).
The key problem that I am trying to solve here, is to allow that automatic mechanism of labeling to be predictable, so a user can manually enter the IDs of the cores into the connection definitions (see the TOML files I posted in response to kpreid).
I am fine separating out the display identifier and the in-file identifier (and in fact I already have) but that doesn't solve the issue of having predictable identifiers for users to use in the connection definitions.
I didn’t mean that the users should ever work with these unique assigned IDs. They should be an internal implementation detail, because they aren’t stable over edits. I think your users should be working with paths — like, as I said, Rust paths to items in modules. The paths can be explicitly shortened by a cable definition giving an alias for one of its components’ components.
I can see the paths method as a path forward (no pun intended) for the users in the TOML files.
so the idea would be to assign each core and core within a core, a generated ID, so I could ahve the equivalent of a flat-map of cores, without having to recurse each time?
I am still a little bit confused about the benefits of the generated IDs, if I still have the nesting there.
Sorry, I am a bit tired and not tracking as well today.
That's right. The generated IDs can be Copy (numbers or newtypes of numbers), which makes them a lot easier to work with in code, and harder to misinterpret, because the paths will be relative to “the current cable”, but the program needs to look at the whole picture, and it will be easier to get that picture right if the IDs of the wires at each end of a connection don't need to be interpreted relative to their cable definition.
