Implement conversion/type expressions

[katcharov]

JAVA-4802

[katcharov]

Some of the TODOs cover the same topic; I've left a comment covering each topic covered by all TODOs. With the exception of the TODO, the code marked by it is not a draft, but is usually something I want to highlight or am not entirely satisfied with (but have considered good enough).

[katcharov]

See comments above. I have not exposed any of the isBoolean/isArray/etc (returns BoolEx) expressions, since it seems that the methods below cover what users need them for (isBooleanOr, which is an "opposite" to ifNull, which I think is preferable). Other possible usages would be covered by switch. But perhaps there is some reason to expose these that I am missing.

[stIncMale]

We can always expose those methods in the future if we discover that we can't get by without doing so.

[jyemin]

Other possible usages would be covered by switch.

How so? It also surprised me not to see these methods.

[katcharov]

There seem to be only the following cases where isBoolean and the rest are are needed:

1. When doing pattern-matching (comparable to a group of if-instanceof blocks in Java). Switch is always a better way to model this, when there is more than one type being checked.

something.switchMap(on -> on
                .isBoolean(v -> v.asString().concat(of(" - bool")))
                .isNumber(v -> v.asString().concat(of(" - number")))
                .isString(v -> v.asString().concat(of(" - string")))
                .defaults(v -> of("something else"))
...

2. When the value is being checked against only one type, we use something like isBooleanOr(<defaultBolean>), which is conceptually shorthand for the following (though the generated MQL is different).

something.switchMap(on -> on
                .isBoolean(v -> v)
                .defaults(v -> <defaultBoolean>)
...

This case arises in the getField(f, default) methods, to allow users to get fields that they cannot assert contain only one type of value (this also covers null and missing, since those are not, for example, booleans).

3. As @stIncMale brought up elsewhere, we might need array.filter(v -> v.isBoolean()).map(v -> v.isBooleanOr(true)), but it is better to provide something like our switch's pattern-matching for this, so array.filterToIntegers or something more suitably named. This reduces the boilerplate and gets rid of the unused default value true.

Apart from the above (which are all variations of the same theme of mapping to an alternative based on type), there seems to be no common case where these isType checks would be used (and the rarer cases can all be modelled using switch(on->isType(...).defaults(...)) if it comes to that).

[jyemin]

There seem to be only the following cases

I don't buy this argument. How is this any different than instanceof in Java? Often it's the only condition in a swittch/if, but sometimes it's combined with other conditions, e.g. if (foo instanceof Bar || foo instance of Baz). It would kind of stink if the language syntax prevented that.

[katcharov]

The language does not prevent the unusual case you describe:

something.switchMap(on -> on
                .isBoolean(v -> of(true))
                .isNumber(v -> of(true))
                .defaults(v -> of(false)).not()

I say "unusual" because I spot checked our codebase for composite instanceof, and saw only ~5/100, and even those all seemed improbable in our API. In any case, the alternative, using isBoolean, seems less elegant even for the code fragment you provided:

var isBooleanOrNumber = v -> v.isBoolean().or(v.isNumber())
something.apply(isBooleanOrNumber).not()

The rationale for excluding it is not just YAGNI (which is itself a fair rationale). If we exclude it, users attempting to check types are forced into a "pit of success" for the most common cases, such as :

something.switchMap(on -> on
                .isDate(v -> v)
                .isString(v -> v.parseDate()))

If we expose the "isType" methods, users would gravitate towards the following:

something
        .isDate().cond(v, something
                .isStringOr(of("not used")).parseDate())

This is not as readable, requires an unused construct, and it is less maintainable (imagine that you must now check something for integer milliseconds - consider how immediately obvious the code change is to the switchMap, versus the example using isDate immediately above.

1. Still trivially possible to do everything, and in a syntax that is arguably superior
2. Forces users into a substantially better syntax for the most common cases
3. Maintains "a single way of doing things" within the API
4. YAGNI
5. We can always add these later but cannot remove them

[katcharov]

Discussed, and agreed that these can be added later if needed (and we will have more info to decide this later).

[stIncMale]

.

[jyemin]

Other possible usages would be covered by switch.

How so? It also surprised me not to see these methods.

[jyemin]

I'm not satisfied with parseNumber yet.