Refactoring #2475

Parameterization: BaseMaterialImpl: typeID

Added by wuttke 3 months ago. Updated about 1 month ago.

Status:RejectedStart date:11 Jul 2020
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

replace it by some object-oriented mechanism

History

#1 Updated by rbeerwerth 3 months ago

Why should this existing mechanism not be used?
It uses the modern enum class es, hence there should be no unexpected confusions and it provides a very readable way of distinguishing the materials in code.
I am absolutely not sure how many changes on the materials machinery will be necessary according to the roadmap, or how much of this will be realized at higher level in the GUI. For the moment, my recomendation is not to touch this isolated, but, if at all, in a concentrated effort after finalizing requirements regarding material parameterization and when deciding how and where to implement them.
I think, we should create an envelope task "Materials" where the whole complex should be analyzed, starting with the status quo and what changes are necessary.

#2 Updated by wuttke about 1 month ago

  • Subject changed from replace typeID in BaseMaterialImpl to Parameterization: BaseMaterialImpl: typeID
  • Status changed from New to Rejected

Closing for now. Question may need to be reconsidered in the general context of parameter handling.

Also available in: Atom PDF