Add Types{,Ref}::{imports,exports} getters

[coolreader18]

I'm not sure if there was a reason this wasn't a thing, but afaict validator::core::exports::Module::exports/imports is never accessed to get() at one of their entries, only ever to insert stuff into them. This seems like a missing piece of the API, sorta.

[alexcrichton]

Seems reasonable to me to add! Could the return values here though be an impl Iterator rather than the internal representation? The imports representation in particular is a bit wonky to work with.

[coolreader18]

Oh, I was hoping to use it as an IndexMap; ModuleType/ComponentType also have imports/exports public as a IndexMap. Maybe if the Vec<EntityType> was wrapped in a ImportType struct or something?

[coolreader18]

Or an ImportsMap that works similar to a multimap or something, since that seems to be what it's functioning as.

[coolreader18]

Or actually it's not even really an IndexMap at all, is it? Internal representation should be more something like { indices: Vec<(String, String, usize)>, entries: HashMap<(String, String), Vec<EntityType>> }, since the imports are actually referred to by their index in import index space. Oh maybe like OrderedMultiMap?

[coolreader18]

Ok I know that's like, a whole new datastructure I just added, but it's really just a simple wrapper around a hashtable (or, simple if you know how hashmaps work, at least)

[alexcrichton]

Thanks for this, but sorry to clarify I dont think that this necessarily needs a whole new data structure. I was instead thinking that an -> impl Iterator<...> could be returned which internally did something like a .flat_map(..) to get hte flat iterator.

[coolreader18]

Yeah, the RawTable probably was a little bit overkill... but I was thinking that since the full IndexMaps were exposed for the other methods, it'd make sense to have at least something with get() available here (that was my use case at least, to use it as a map rather than a vec). Also, the ImportMap was to fix a (theoretical?) correctness issue where if you flatten imports as an IndexMap, the iterator would return import entries in a different order from what they were in the module which now looking at the code that does the typechecking is not actually an issue at all.... hm. How about keeping ImportMap, but just as like a wrapper around a IndexMap<(String, String), Vec<EntityType>>, with a get(module: &str, name: &str) -> Option<EntityType> and a disclaimer that its iterator is not in the same order as the imports in the module? Or just an impl Iterator if that's still preferred, I've realized I'm sorta making a big deal out of this for nothing lol.

[alexcrichton]

I do think that iteration order here will be important and should match what was specified in the original module. I forgot that IndexMap was already exposed so exposing such a map for exports seems reasonable. For imports perhaps the impl Iterator could be exposed for iterating over everything and a specific method could be added for looking up a specific import?