Christoph Ortner

> To me the interface is defined by the documentation of what is returned, rather than how it is stored internally. yes, exactly. > It would be nice to have...

Generally speaking, `AtomsBase` is about interfaces, not about concrete implementations. In order to not waste more time here, how about @ejmeitz implements whatever works best in your visualisation package and...

One last comment from me: > .. would return different things on the same system. First, I'm not sure it really matters. It's just two different neighbour lists for the...

See my implementation of particle `State`s in `ACE.jl` - that's exactly what it provides. It could potentially move here, or it could inspire a new and better implementation here.

For exactly that reason we used a wrapped integer in JuLIP but allowed easy translation to a Symbol. With a bit of work the display could even show the symbol...

Then I'll promote again my implementation in ACE.jl of wrapped NamedTuples. https://github.com/ACEsuit/ACE.jl/blob/main/src/states.jl https://github.com/ACEsuit/ACE.jl/blob/main/test/test_states.jl

I thought we are talking about a prototype implementation. Indeed I don't think the interface can depend on any type parameters at all. Just on getter functions.

I guess if you want an abstract CHARMM then just implement a new function isCHARMM which defaults to false?

> But what interoperability could we get from that interface, at all? If the getters are defined and documented in a public interface, that's all you need for interoperability I...

What you suggest makes sense in Java but not in Julia. Abstract super types are not needed to define an interface but are only needed to share methods. At the...