Non-reifiable types and obj.isInstanceOf(type)

[HosseinYousefi]

However it's important to note that instanceof requires a reifiable type. If we simply ignore this, users will get false positives because of generic type erasure.

One way is to require a JClass instead, so we have obj.isInstanceOf(type.jClass). But it's still not obvious that list.isIntanceOf(ArrayList.type(JInteger.type).jClass) can be true when list is in reality ArrayList<String>!

So either

1. We want to introduce the functionality but warn people about type erasure in docs
2. Or introduce yet another JReifiableType type tree (and accessing them byFoo.reifiableType) and only accept that for isInstanceOf.

Wdyt @dcharkes?

[dcharkes]

1. We want to introduce the functionality but warn people about type erasure in docs

I presume developers experienced with Java/Kotlin will know about type erasure. So mentioning it in docs should ring a bell for those users. (I remember the days I first ran into this... 😅)

Or introduce yet another JReifiableType type tree (and accessing them byFoo.reifiableType) and only accept that for isInstanceOf.

This would be nice indeed. It forces users to "read the docs" by power of the type checker. How would this work exactly?

It's still not obvious that list.isIntanceOf(ArrayList.type(JInteger.type).jClass) can be true when list is in reality ArrayList<String>!

What is reality here? The static type or the dynamic type? At runtime there is no type argument, so basically it's always ArrayList<Object> (where Object is nullable) at runtime.

Shouldn't this issue be named "Non-reifiable types and instanceOf"? And JNonReifiedType + Foo.nonReifiedType? Or am I misunderstanding what you are trying to achieve here?

Maybe it should just be Foo.runtimeType and JRuntimeType. (And maybe we can make the runtime-type hierarchy be the same objects/classes as the static-type hierarchy for all non-generics?)

[dcharkes]

From discussion offline:

Option 1: list.isIntanceOf(ArrayList.jClass) if we type check against the JClass, because the class handle has generics erased by definition. Possible downside: more handles.

Option 2: Uninstantiated type hierarchy. Unbound type parameters. (Downside: surgery.)

Option 3: The static type hierarchy, but all type arguments must be instantiated to bounds. (ArrayList.type(JString.type) is not allowed, ArrayList.type(JObject.type). We can prevent people having to write having the bounds by adding a ArrayList.rawType.