On Wednesday, 4 February 2015 20:02:43 UTC, Josh Langsfeld wrote:
>
> On Wed, Feb 4, 2015 at 2:29 PM, Christoph Ortner <[email protected]
> <javascript:>> 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.
>
Yes, I see that - I was primarily concerned whether this was "good style".
> 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.
>
Indeed, most Calculators need no more than AbstractAtoms type information,
but need to know nothing about which subtype.
After this discussion, I think this is the way I will go. Thanks a lot.
Christoph
