Open Tokazama opened 2 years ago
I like the idea, but I'm not sure about overloading the term "keys" as that already means something else for an array.
Do you have anything in mind that would more clearly convey what the method should return?
Sorry forgot to answer, but no. I've struggled with this too.
I'm pretty sure what we are all talking about is "keys" of some sort, but the concept of keys hasn't been formalized into a dedicated abstract interface in Julia yet. I think the definition of keys(::AbstractArray)
in base is mostly so that functions can work generically with dictionaries and arrays, not necessarily a formalization of that interface. So my opinion is that anything that doesn't break those generic functions is fine. But I'm always open to alternative suggestions.
FWIW, I think calling these "keys" in my package was a mistake, as Base.keys
already has a meaning. (And because these are auxiliary info, if you are using them to look up entries often, then you probably want a dictionary not an array.) "Labels" would have been better.
IRC, @ChrisRackauckas didn't like "labels" when this was discussed (well over a year ago).
I'm assuming this won't get more attention until after people have more time freed up after JuliaCon. I'd be fine if we changed from axes_keys
to labels
, but I think it is at least as problematic as using the term "keys". For example, if I have a time series recording of subject data I want the time to be the keys and events to be labels/annotations. There can also be multiple layers of conceptually independent labels. That has a place but I'm specifically thinking of what we call the key-value relationship.
@rafaqz and @mcabbott, what do you think about having this method defined here to to interfaces together?