-
Couldn't load subscription status.
- Fork 20
Description
What happened?
The current hierarchy is:
classDiagram
Report <|-- _Report
Report <|-- BatteryPoolReport
The problem is BatteryPoolReport is a _Report, and _Report is the concrete class sent through channels, so there are instances when a _Report needs to be converted to a BatteryPoolReport, for which we just need to go behind the back of the type system.
What did you expect instead?
If I have a Receiver[_Report], I expect to be able to safely return a BatteryPoolReport from it without any casting.
Affected version(s)
No response
Affected part(s)
Battery power distribution (part:power-distribution)
Extra information
So, the naive solution is:
classDiagram
BatteryPoolReport <|-- _Report
But of course this doesn't work in the whole context of Report. In the current code, there are no other Reports that are not BatteryPoolReport, so I'm not sure how the end use of this hierarchy should look like. If it is just documentation, I'm not sure it is worth hiding _Report, I think it would be simpler to just keep it generic and then have something like:
Note
When applied to different components, the attributes of this class have different meanings.
BatteryPool: component IDs are battery IDs. Yada yada yada- Etc.
Also I wonder if we can solve this by using completely different types for different Report types, that have no inheritance relationship, are all concrete classes and instead make Report = BatteryPoolReport | PvPoolReport | .... Then we can use the match syntax to know what we received from the channel.
I guess we also need to mix all these different reports in the same channel because we are going to use the same power manager for all, because ideally we should just use one concrete type per channel and then we don't need the hierarchy or the type alias at all.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status