Thoughts on Paths - microbean/microbean-settings GitHub Wiki

A Path is a path of qualified types.

(It just occurred to me that if you really want to reduce things a type is a qualifier named type with a value of, effectively, all of its supertypes. Thus in this limited view a Path is a path of Qualifiers instances. This may be taking it too far in most cases but it's worth bearing in mind when it comes to path matching.)

Each type is qualified with regular qualifiers, and, except for the first one, is qualified by the way you reach it. Note that the application itself (the root) can be qualified too.

A Car for example can be qualified itself (with "myFavorite"). If you use its getEngine method to get an Engine, then the qualified type for Engine has whatever qualifiers Engine in general has on it plus some representation of getEngine itself. The representation might be the method name, or its signature, or even maybe its arguments as well.

We can represent this as a path: /;env=test;stability=bad/Car:value=myFavorite/Engine;accessor=getEngine

Here, the application is qualified with env=test and stability=bad. The Car itself is qualified with myFavorite. The Engine is qualified with the accessor used to "get" it (accessor=getEngine).

Here's a more complicated one:

  1. Application:env=test;stability=bad # Application is some magic type that represents the overall app
  2. Car:value=myFavorite
  3. Wheel:accessor=getWheel;arg0="LF" # hmm; someone wanted the left front wheel

This is like, in CDI: select(Wheel.class, appQualifiers, carQualifiers, getWheelQualifier, justInTimeQualifierContainingLF).

Anyhow: this path-like thing is, just like CDI, an injection point of sorts, as well as a potential representation of what a provider might bear. That is: in the examples above, this is what the user is asking for. Someone has made a call to Settings.get(Car.class, "myFavorite").getEngine(), and that demand has to be satisfied. The path is the demand.

On the provider side, there might be many providers "assignable to" this path, this demand, whatever we want to call it. In CDI this is like a bean bearing qualifiers, just as an injection point bears qualifiers: the injection point might call for a @Red Car and on the bean side there might be @Red @Heavy Ferrari and @Red Truck.

Is there a @Default-like qualifier in play? Maybe conceptually but in reality the requestor is usually prepared for there to be many satisfiers. In CDI that's true as well, but the resolution kind of occurs under the hood. Any request may return multiple beans, even one where the qualifiers match, due to alternates. Then a resolution process kicks in and weeds things out. Here, it's the same sort of thing.

Additionally, in configuration DI like this, the requestor is never asking for an unqualified value or one that is implicitly qualified by @Default, with the only possible exception being the root of the path. Someone might do Settings.get(Car.class), for example, in an application that is itself unqualified, and expect the "default" Car, whatever that is. But after that point, car.getEngine() yields at least one qualifier ("getEngine").