Re: [RFC PATCH 0/7] dts: revamp framework

[Luca Vizzarro <Luca.Vizzarro@arm.com>]

On 04/02/2025 21:08, Dean Marx wrote:
> Hi Luca,
> 
> I saw in the meeting minutes that the main purpose of this series is
> to implement the separation of concern principle better in DTS. Just
> wondering, what parts of the current framework did you think needed to
> be separated and why? I'm taking an OOP class this semester and we
> just started talking in depth about separation of concerns, so if you
> wouldn't mind I'd be interested in your thought process. Working on a
> review for the series currently as well, should be done relatively
> soon.
> 
> Thanks,
> Dean

Hi Dean,

For starters all the major logic was held within the `runner.py` file, 
which is not ideal. When some logic touches the same object too often, 
maybe its an indicator that it actually belongs to that class instead. 
For example, the test suite and cases are configured within the 
configuration. Anything configuration should be kept within the 
configuration, the runner should assume that the configuration is final 
and is ready to be fed to the classes. For this reason, I've moved the 
test suite and cases filtering logic there. Test runs are a whole 
concept on their own, and they have their own logic. For this reason it 
is a better idea to have them individually in their own dedicated class 
where they can control themselves. As opposed to having a runner.py 
basically dealing with every part of the framework in the same place. If 
you were to make a graph with all the linked classes to runner.py, I am 
sure it'd look like spaghetti. We don't want that. We want a hierarical 
and structured approach. Separation of concerns will aid this by keeping 
things where they belong, minimising import/export. This will also help 
with circular import issues.

Hope this provides some insight!

Luca