Many thanks for the discussion. On Wednesday, 4 February 2015 16:46:09 UTC, Josh Langsfeld wrote: > > For me, option 1 looks the most Julian. Maybe the clunkiness is arising > because the calc object shouldn't be a field of Atoms? Fields are just > suppose to store data, not logic or methods. >
Indeed, that is how I use them. But the Calculator stores, e.g., model parameters. > If a certain subtype of AbstractAtoms always uses the same calc object, > then dispatching just on the atoms should be sufficient. > Unfortunately, that is not the case. > If it can vary, maybe it would be more elegant to associate them together > in some other way than a type field and then directly dispatch on both > values. > This was my initial thought as well. The problem with that is that the Atom and Calculator, NeighbourList and Preconditioner objects are "linked": when Atoms is updated, then a "message" is sent to Calculator, Preconditioner and NeighbourList so that they can update themselves also. The Calculator, NeighbourList and Preconditioner objects in fact store additional data that is dependent on the data stored in Atoms. > Also, for option 2, why couldn't you give both AbstractAtoms and its > subtypes just a single type parameter for the calculator? > Because the same issues arise for NeighbourLists, for Preconditioners and potentially other objects that will be linked to Atoms type objects. I wonder whether I am making things too complicated here?
