Class ElementImpl
- All Implemented Interfaces:
Element
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescription<T> Optional<T> Perform the same lookup asElement.get(String, Class), except allow for full type inferencing when possible.<T> Optional<T> Hierarchic get of a named variable.getMap()Return the backing data for this element in map form.<T> TPerform the same lookup asElement.get(String, Class), but return the default value when a value isn't found.toString()
-
Constructor Details
-
ElementImpl
-
-
Method Details
-
getElementName
- Specified by:
getElementNamein interfaceElement
-
get
Description copied from interface:ElementHierarchic get of a named variable. If the name is a simple word with no dots, such as param2, then this is a simple lookup. If it is a hierarchic name such as car.cabin.dashlight1, then multiple representations of the structure could suffice to serve the request. This is enabled with name flattening.
Name flattening - It is possible that multiple representations of backing data can suffice to hold the same logically named element. For example the three JSON objects below are all semantically equivalent.
[ { "car": { "cabin": { "dashlight1": "enabled" } } }, { "car": { "cabin.dashlight1": "enabled" } }, { "car.cabin": { "dashlight1": "enabled" } }, { "car.cabin.dashlight": "enabled" } ]It is necessary to honor all of these representations due to the various ways that users may provide the constructions of their configuration data. Some of them will be long-form property maps from files, others will be programmatic data structures passed into an API. This means that we must also establish a clear order of precedence between them.
The non-collapsed form takes precedence, starting from the root level. That is, if there are multiple backing data structures for the same name, the one with a flattened name will NOT be seen if there is another at the same level which is not flattened -- even if the leaf node is fully defined under the flattened name.
Thus the examples above are actually in precedence order. The first JSON object has the most complete name defined at the root level, so it is what will be found first. All implementations should ensure that this order is preserved.
This method requires a type which will be given to the underlying
ElementDataimplementation for contextual type conversion. -
get
Description copied from interface:ElementPerform the same lookup asElement.get(String, Class), except allow for full type inferencing when possible. The value asked for will be cast to the type T at runtime, as with type erasure there is no simple way to capture the requested type without reifying it into a runtime instance in the caller. Thus, this method is provided as a syntactic convenience at best. It will almost always be better to useElement.get(String, Class) -
getOr
Description copied from interface:ElementPerform the same lookup asElement.get(String, Class), but return the default value when a value isn't found. -
getMap
-
toString
-