Leandro Martínez

Y just saw at the state of julia talk that base will already provide the warning message, in exactly this format. So we definitely can close this.

Coming late to the discussion, I have just posted a comment on the Zulip chat about something related. I think both the for `System` or for `Atom`, we could have...

> the type of `atomic_symbol` to a parameter. I would follow what Cortner suggested, just store the atomic number and make the symbol, or string atomic name, something to be...

That right, one more reason to allow a typed extra data field. Then the atomic type information can be stored there in any format needed, and there are many formats...

The issue I see with that approach is that it does not enforce *anything*. It is almost as saying that the interface is just a commitment to the implementation of...

But what interoperability could we get from that interface, at all? That's what I miss. Why then `Atom` here is exported at all?

> I think it is intended as a minimal prototype. Ok, so from this point of view the `Atom` struct is a minimal prototype. Then, a few questions: Is the...

What I can imagine is something like: ```julia julia> abstract type AbstractAtom end julia> charge(::AbstractAtom) = "not implemented" charge (generic function with 1 method) julia> atomic_number(::AbstractAtom) = "not implemented" atomic_number...

Well, it is a way to inform what the interface expects. And methods implemented across packages can be type annotated on the abstract type to inform that the function in...

Do people here agree, at least, that this issue of *arbitrary properties* is not really fundamental, at least? Meaning, that if one implements these 6 getters: https://juliamolsim.github.io/AtomsBase.jl/stable/apireference/#Species-/-atom-properties the interface of...