Skip to content

E003a restructure#441

Merged
adeas31 merged 1 commit into
OpenModelica:masterfrom
syntron:E003a-restructure
Jun 26, 2026
Merged

E003a restructure#441
adeas31 merged 1 commit into
OpenModelica:masterfrom
syntron:E003a-restructure

Conversation

@syntron

@syntron syntron commented Feb 27, 2026

Copy link
Copy Markdown
Contributor

restructure - part1: collect all ModelExecution classes in one file

@adeas31

adeas31 commented Jun 22, 2026

Copy link
Copy Markdown
Member

Please rebase.

@syntron syntron force-pushed the E003a-restructure branch from 3da0c6b to d494b90 Compare June 25, 2026 19:47
@syntron syntron force-pushed the E003a-restructure branch from d494b90 to 933199b Compare June 25, 2026 20:02

simargs[parts[0]] = override_dict

return simargs

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The classes names sounds a bit confusing to me.

ModelExecutionData (currently a dataclass) actually does things — it has get_cmd() and run() methods. It's the active executor.

ModelExecutionCmd (currently a regular class) is purely a builder/configurator — it accumulates arguments via arg_set(), args_set(), arg_get(), and ultimately produces a ModelExecutionData instance via definition(). It holds no executable logic itself.

  • Something called ...Data should be a passive data holder (which is exactly what a @dataclass normally is), and
  • Something called ...Cmd suggests an active command runner.

But right now it's the opposite: the @dataclass runs the process, and the class called Cmd just builds up configuration.

If you want to make the roles clearer without changing much, something like ModelExecutionConfig (for the builder that accumulates args) and ModelExecutionRun (for the dataclass that actually executes) would remove the ambiguity entirely rather than relying on Cmd vs Data to carry the distinction.

What do you think?

@syntron syntron Jun 26, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with the renames; would it be OK to do this after the restructure (E003a to E003c)? Else it will quite some work on modifying the data again and again ... I could create a PR for this on top of E003c or F001.

The restructure just move classes and adapt imports, etc. - no change to the content of any class!

Background (as you stated; via a long way of development):

  • the dataclass collects all the data and has the (minimal) function to execute it
  • the other class is just responsible to build / create all the needed variables of the dataclass

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I will merge this and you can put the change on top.

@adeas31 adeas31 merged commit 28536fd into OpenModelica:master Jun 26, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants