SimpleConfigList

Compares the receiver object (this) with the argument object (that) for equivalence.

Any implementation of this method should be an equivalence relation:

• It is reflexive: for any instance x of type Any, x.equals(x) should return true.
• It is symmetric: for any instances x and y of type Any, x.equals(y) should return true if and only if y.equals(x) returns true.
• It is transitive: for any instances x, y, and z of type Any if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.

If you override this method, you should verify that your implementation remains an equivalence relation. Additionally, when overriding this method it is usually necessary to override hashCode to ensure that objects which are "equal" (o1.equals(o2) returns true) hash to the same scala.Int. (o1.hashCode.equals(o2.hashCode)).

Super-expensive full traversal to see if descendant is anywhere underneath this container.

Calculate a hash code value for the object.

The default hashing algorithm is platform dependent.

Note that it is allowed for two objects to have identical hash codes (o1.hashCode.equals(o2.hashCode)) yet not be equal (o1.equals(o2) returns false). A degenerate implementation could always return 0. However, it is required that if two objects are equal (o1.equals(o2) returns true) that they have identical hash codes (o1.hashCode.equals(o2.hashCode)). Therefore, when overriding this method, be sure to verify that the behavior is consistent with the equals method.

This is used when including one file in another; the included file is relativized to the path it's included into in the parent file. The point is that if you include a file at foo.bar in the parent, and the included file as a substitution ${a.b.c}, the included substitution now needs to be ${foo.bar.a.b.c} because we resolve substitutions globally only after parsing everything.

Replace a child of this value. CAUTION if replacement is null, delete the child, which may also delete the parent, or make the parent into a non-container.

Called only by ResolveContext.resolve().

Recursively unwraps the list, returning a list of plain Java values such as Integer or String or whatever is in the list.

The [[ConfigValueType]] of the value; matches the JSON type schema.

Returns a ConfigValue based on this one, but with the given origin. This is useful when you are parsing a new format of file or setting comments for a single ConfigValue.

Places the value inside a [[Config]] at the given key. See also ConfigValue#atPath.

Places the value inside a [[Config]] at the given path. See also ConfigValue#atKey.

The origin of the value (file, line number, etc.), for debugging and error messages.

Renders the config value to a string, using the provided options.

If the config value has not been resolved (see [Config.resolve()), it's possible that it can't be rendered as valid HOCON. In that case the rendering should still be useful for debugging but you might not be able to parse it. If the value has been resolved, it will always be parseable.

If the config value has been resolved and the options disable all HOCON-specific features (such as comments), the rendering will be valid JSON. If you enable HOCON-only features such as comments, the rendering will not be valid JSON.

Renders the config value as a HOCON string. This method is primarily intended for debugging, so it tries to add helpful comments and whitespace.

If the config value has not been resolved (see Config.resolve()), it's possible that it can't be rendered as valid HOCON. In that case the rendering should still be useful for debugging but you might not be able to parse it. If the value has been resolved, it will always be parseable.

This method is equivalent to render(ConfigRenderOptions.defaults()).

Returns a string representation of the object.

The default representation is platform dependent.

Returns a new value computed by merging this value with another, with keys in this value "winning" over the other one.

This associative operation may be used to combine configurations from multiple sources (such as multiple configuration files).

The semantics of merging are described in the spec for HOCON. Merging typically occurs when either the same object is created twice in the same file, or two config files are both loaded. For example:

 foo = { a: 42 }
 foo = { b: 43 }

Here, the two objects are merged as if you had written:

 foo = { a: 42, b: 43 }

Only [[ConfigObject]] and [[Config]] instances do anything in this method (they need to merge the fallback keys into themselves). All other values just return the original value, since they automatically override any fallback. This means that objects do not merge "across" non-objects; if you write object.withFallback(nonObject).withFallback(otherObject), then otherObjectwill simply be ignored. This is an intentional part of how merging works, because non-objects such as strings and integers replace (rather than merging with) any prior value:

 foo = { a: 42 }
 foo = 10

Here, the number 10 "wins" and the value of foo would be simply 10. Again, for details see the spec.