Subtyping and retrieval

[ljnelson]

What is the committee's collective opinion, if there is one, on subtyping during retrieval?

I will deliberately use the stupidest possible names I can think of to illustrate my point so that we don't get hung up on an API.

Again the API below is not important. The typing information is.

Consider:

final CharSequence greeting =
    jakartaConfigSystemRetrieverLoaderThing.retrieve(someKindOfAddressingInformation, 
                                                     CharSequence.class);

And now let us say that an implementation of retrieve ends up finding a String (an implementation of CharSequence). Should the retrieval succeed? It is a subtype match, not an exact match. (Surely yes?)

What about:

final Frobnicator<Map<String, Integer>> f =
    jakartaConfigSystemRetrieverLoaderThing.retrieve(someKindOfAddressingInformation,
                                                     new GaftersGadget<Frobnicator<Map<String, Integer>>>() {}.type());

…where GaftersGadget embodies Gafter's gadget in much the same way as jakarta.enterprise.util.TypeLiteral.

And now let us say that an implementation of retrieve ends up finding a SubFrobnicator<Map<String, Integer>> (a subtype of Frobnicator<Map<String, Integer>> if I am typing things right and have my parameterized type assignability rules correct—in any event, you get the idea). Should the retrieval succeed? It is a subtype match, not an exact match.

Assuming the retrieve operation is backed by multiple sub-providers ("config sources") (which of course is not a given nor required by the API but yet often assumed by the committee as a given), should it be able to distinguish between a provider that finds a Frobnicator<Map<String, String>> and a Frobnicator<Map<String, Integer>> and pick the right one? If so, what runtime type assignability semantics is it using? Straight-up Java's? Or will there be restrictions? If so, which ones?

In short:

If both of these examples should work, what are the type assignability rules we're going to outline? Are they CDI's, basically?

If neither of these examples should work, how should the retriever user interrogate the system to discover what types of things she can retrieve, given that, by definition, the types of things she wants to retrieve (the types she uses at compile time) will stand the possibility of being different from the types of things that are available at runtime?

[dmlloyd]

Here's my thoughts, hopefully this helps.

From our discussions thus far, and the initial code dumps, I have come away with the understanding that (like MicroProfile Config), the config source is not concerned with types (generally speaking), and the "raw" value from the source would (somehow) be transformed using a typed converter (e.g. Converter<T>). That being the case, I'd expect that all of the complex type conversion gymnastics would be handled by the converter, something like this:

final MyThing<Foo, Bar> myFooBarThing = config.get(configPathOrKey, myFooBarThingConverter);

Additionally, MP Config has provided API methods for simple non-generic type conversions which accept a Class<T>, and Optional<T> variants as well. The SmallRye implementation (this is the one that @radcortez maintains) also provides variants for collections of simple types. The registered and default converters would generally only correspond to simple types.

I don't think we want to mess around with complex type token schemes; that's probably biting off too much in one go. Between the ability to use an explicit converter on retrieval, and the object binding layer which can do much more sophisticated things, I've found this approach to be adequate even for complex use cases, at least within the context of Quarkus.

[ljnelson]

Thanks for your reply.

Looking just at the API (which I know, I said doesn't matter, but looking just at the type part of it), I don't care whether there are converters or caturgiators or whizbangfoobishers or MP config or anything else of that nature involved: someone supplies some addressing information and a type to a retrieval-like method, and expects a value back. My question is: in the specification, what types can the class developer supply? And therefore what values may be returned to her? I hear you essentially saying some types and some values, but not all. Is that correct?

[radcortez]

I think either type that complies with the type mapping rules (we started that discussion here: #73) is similar to a JPA or JSON-B object type mapping or binding. Or a type that we know that we can convert, but we haven't got into the Converter part, so this is still a little bit hazzy.