On Wed, Feb 4, 2015 at 2:29 PM, Christoph Ortner <[email protected] > wrote:
If I read this correctly, then what you are saying is that I am allowed to > assume that my concrete abstract subtypes will contain certain fields, and > if they don't then too bad for them, they need to go and re-implement some > of the structure that I provide for AbstractAtoms. > Basically, if you know all subtypes of AbstractAtoms have a field 'num' then 'getnumatoms(a::AbstractAtoms) = a.num' will work fine and will only error if any new subtype doesn't have the field. However, if the AbstractAtoms structure relies on that field existing and it doesn't make sense to have it for a certain subtype, then the structure has to be refactored to rely on methods instead, which can be (NOT must be) reimplemented by the subtypes. How about this then; in this case a new AbstractAtoms sub-type or a new > AbstractCalculator sub-type would not need to implement the "interface" > get_forces(a), but only the get_forces(a, c). > That would certainly work, though ideally there would be no need to defined the interface to be coupled like that. There should be an abstraction of all calculator types that would provide whatever methods get_forces needs to do its thing. Or maybe it's reversed with specific Calculator types able to depend on AbstractAtoms only. Either way, you wouldn't need a get_forces(a,c) method for every possible type a and c can take.
