Allow easy adding of new materials

[MicahGale]

Right now to add a material you have to append it to: problem.materials and problem.data_cards which is very error-prone. I think this will require significant reimagination of what data_cards does. It has to balance storing original input order as well as allowing sorting of data cards.

[MicahGale]

@bascandr just got tripped up by this issue. I think this should be escalated to a bug as it is unintuitive, and is not documented anywhere.

The quick fix would be to remove materials from the data cards and then just print them all in one block separate from other data cards. Is that a deal breaker @bascandr?

Current workaround:

new_mat = Material(...)
problem.materials.append(new_mat)
problem.data_cards.appends(new_mat)

[MicahGale]

Also there is also the work around of using problem.add_cell_children_to_problem() (name may differ slightly). Should these additions happen instantly? Like when you add a new material to a cell that isn't in the current problem should it just get added?

[MicahGale]

In GitLab by @bascandr on Mar 8, 2023, 08:29

Everything makes so much more sense now. Lumping all of the materials at the end generally wouldn't be a problem for me, but I could see it making some types of input/formatting difficult to follow (material defined right before a tally multiplier that uses it for example).

I think clear documentation could solve most of this (in the unlikely event that you can get users to read it). A more long term improvement may be to add a method to problem.materials to allow it to automatically add newly created materials to the data_cards.

[MicahGale]

Right and probably vice versa too.

[MicahGale]

Idea: we make data_cards a NumberedObjectCollection derivative.

[MicahGale]

I think for now at least the solution is to:

1. subclass NumberedObjectCollection something like NumberedDataObjectCollection.
2. overwrite append which would insert the appended item after the last object of this type in problem.data_inputs.

Questions:

1. What should happen if a collection is detached from a problem? Should this data_inputs step be skipped or should a fatal error occur?
2. Should the appended object be linked to the new problem? Should the appended object be cloned?

[tjlaboss]

What should happen if a collection is detached from a problem? Should this data_inputs step be skipped or should a fatal error occur?

It should continue to work if the collection is detached from a problem. This might mean keeping a local list of data_inputs associated with the NumberedDataObjectCollection in an attempt to preserve their positions, or else just appending/append_renumbering the contents of NumberedDataObjectCollection.values() when next connected to a problem.

[tjlaboss]

Should the appended object be linked to the new problem? Should the appended object be cloned?

The appended objects should be cloned. This is less likely to lead to user confusion.

[MicahGale]

I'm not sure if agree though. Having append always clone will lead to some weird behavior, and renumbering.