Survey on primitive type test patterns

[Ryan Schmitt]

I'm not sure I agree with your "Stockholm Syndrome" interpretation of the
survey results. The question you actually asked was simply: "What would you
expect this would mean?" There are two ways of interpreting this question:

(A) Based on your mental model of Java, how would you expect the compiler
to interpret this expression?
(B) In your vision of sanity, how *ought* this expression be interpreted?

By your own admission, the people answering (A) in terms of types are not
wrong. There may in fact be a significant element of Stockholm Syndrome
here (after all, people defend zero-indexed arrays all the time), but I'm
not convinced that this survey has isolated it.

On Fri, Nov 3, 2017 at 9:53 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> You may have seen a survey float by a few days ago, aimed at probing at
> developer intuition about the semantics of primitive type test patterns.
> The results are here, with over 1000 answers:
>
>     https://www.surveymonkey.com/results/SM-87Y6K3BY8/
>
>
> BACKGROUND
>
> The real goal of this survey was to probe at how deep the Stockholm
> Syndrome between Java developers and primitive boxes goes (with an eye
> towards evaluating the semantic options for how to interpret primitive
> type-test patterns).  And the unfortunate answer was, not surprisingly,
> pretty deep.
>
> The seam introduced by boxing is deep and terrible; it messes with the
> most fundamental foundations of computing, numeric equality.  Given:
>
>     Long zl = 0L;
>     Byte zb = (byte) 0;
>
> We have
>
>     zl == 0
>
> and
>
>     zb == 0
>
> but not
>
>     zl == zb
>
> as we would expect from equality being transitive.  (The odd bits of
> floating point, like NaN, mess with this too, but this corner case is more
> likely to stay in the corner where it belongs.)
>
> Which brings us to question 1; what should a constant pattern 0 match?
>
>     Object anObject = ...
>     switch (anObject) {
>         case 0: ...
>     }
>
> There are basically three options here:
>  - It matches (Integer) 0, but not (Long) 0, (Short) 0, etc.
>  - It matches all the primitive zeros, because, well, they're all the same
> zero.
>  - Punt; don't allow numeric constant patterns unless we know more about
> the target type.
>
> The first elevates the primitive boxes (which are really the tail, not the
> dog) to being the "real" numeric types in this case.  This feels like bug
> bait.
>
> The second recognizes that types are merely a convenient way of reasoning
> about value sets, and the value 0 is a member of the Long value set, the
> Integer value set, etc.
>
> The third hides our head in the sand.
>
> Question 2 is the same, just one level up; how do we interpret "case int"
> as a type test pattern (or "x matches int", or "x instanceof int")?  And
> again we have the same choices:
>
>  - Pretend "case int" is really "case Integer" (all hail, primitive box
> types);
>  - Interpret "case int" as "are you a member of the value set described by
> int";
>  - Don't allow that question to be asked.
>
>
> INTERPRETATION OF THE RESULTS
>
> There were three choices that corresponded to "instanceof is about types,
> full stop": 1/2/4.  Each of these choices said, in some manner, that asking
> "are you an instance of int" was a dumb question.  The fourth choice (#3),
> treated "instanceof int" as "are you an int".
>
> #3 is strictly more expressive than the others; it allows you to ask a
> sensible question that was previously hard to ask, and get a reasonable
> answer.  (#1 and #2 let you ask a dumb question and get a dumb answer; #4
> tells you "that was a dumb question.")
>
> The thing we were trying to get at was, whether if we have a Long that
> holds a number, people think the more important characteristic is that it
> is a Long (vs Integer, Short, Byte, or Character), or its value.
>
> This poll told us that: the Stockholm Syndrome is so strong that, when
> given the option to treat boxed numbers as numbers, rather than instances
> of accidental boxes, 85% chose the latter.
>