6 ms·

In Java, you can't make runtime decisions based on the generic type of an object. Eg. you can't have a List<?> and check to see if it's a List<Foo> or a List<Ba

by rusbus 9y ago

In Java, you can't make runtime decisions based on the generic type of an object. Eg. you can't have a List<?> and check to see if it's a List<Foo> or a List<Bar> -- that information has been erased. You could look at the head of the list to make that determination, (because the List members still have a concrete type), but that isn't a general purpose solution. Languages like Scala use manifests to preserve the information but it's a major kludge.

yarg 9y ago
Looking at the head of a List does not work. The class of that element is within the scope of <? extends ListType>, an is not necessarily not ListType.
- rusanu 9y ago
  Not to mention that an empty list still has a type...
- yarg 9y ago
  *and is not necessarily ListType. Idiot.
  - Twisol 9y ago
    For the downvoters, the author is correcting themselves after the edit window. It's clearly self-deprecating humor, not a personal attack.
- Groxx 9y ago
  To spell this out so it's a bit more obvious, given a Thing at head of a list, you could have: - a List<Thing> - a List<ThingSuperclass> - a List<? extends Thing> - a List<? super ThingSubclass> - a List<IThing> - a List<ILiterallyAnyImplementedIFace> - a List<IHaventForgottenInterfacesCanExtendOthers> - a List<Object> - a List<I'm probably forgetting some possibilities> And you have no way of knowing which it is. So yes, it's a boundary, which is significantly more than nothing. But far less useful than it feels like at first.
Gibbon1 9y ago
One the way to looking at other things(tm) I found a blog post by a CS language researcher talking about type erasure. His two points. Being able to do type erasure is great because it means your language is coherent. (Don't need to do any nasty kluges in the run time) And then everyone ratfucks themselves by actually implementing type erasure, and now your language will never have good tooling and thus will die a lonely unmourned death. He commented that C/C++ has type erasure and it's also a massive kludge (via the elf format). No one will invest that much effort into a new language. tl;dr: Type erasure, it's great, don't do it.
- eeperson 9y ago
  What tooling do you think is missing due to erasure?
  - Gibbon1 9y ago
    Not a CS person, but I think if you keep the type information pined to the object in memory then a debugger can use the object type information in memory to match it with the object's definition in the program. That makes creating a debugger easy. Imagine wanting to know what the object at address 0x34199920 is. If you have type info[1] you can cross reference the type info with 'generic array' and then do the same with element 2, address 0x34199920 and know it's a 'foo object'. [1] Say the first 4 bytes is _always_ a type index that the compiler or interpreter generates.
cm2187 9y ago
But then what is the difference between a a collection of type object and a errasure model generic collection?
- kelnos 9y ago
  At the VM/bytecode level, not much (if anything?). The benefit comes at compile-time, where the compiler can verify that you're putting the correct types into a collection, and that you're expecting the correct types out.
  - SideburnsOfDoom 9y ago
    > At the VM/bytecode level, not much (if anything?). I don't think this is correct. In C# code at runtime, and in the bytecode, you can inspect types for metadata about their generic type params. It is present in the .Net bytecode. See https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-and-reflection https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... > When a generic type or method is compiled into (bytecode), it contains metadata that identifies it as having type parameters. from https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-in-the-run-time https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
    - cm2187 9y ago
      But C# generics aren't erasure model collections are they?
      - SideburnsOfDoom 9y ago
        No, they are not. The point is, it is different at the bytecode level.
  - shellac 9y ago
    You've got that completely the wrong way around. An erasing compiler has full access to the type (obviously - it's doing the erasing) and so can verify whether you're putting the correct types in or out of a collection. Where erasure can cause issues is at runtime. For example: X isa List<Int> Even if X is indeed a list of ints that information isn't held at runtime, so the test can't be supported. Having said that in some respects this is a C# / Java ecumenical matter. Haskell, for example, doesn't bake types into output code so I suppose it erases even more that java, but it supports very rich polymorphic behaviour.

by rusbus 9y ago

yarg 9y ago

Looking at the head of a List does not work. The class of that element is within the scope of <? extends ListType>, an is not necessarily not ListType.

rusanu 9y ago
Not to mention that an empty list still has a type...
yarg 9y ago
*and is not necessarily ListType. Idiot.
- Twisol 9y ago
  For the downvoters, the author is correcting themselves after the edit window. It's clearly self-deprecating humor, not a personal attack.
Groxx 9y ago
To spell this out so it's a bit more obvious, given a Thing at head of a list, you could have: - a List<Thing> - a List<ThingSuperclass> - a List<? extends Thing> - a List<? super ThingSubclass> - a List<IThing> - a List<ILiterallyAnyImplementedIFace> - a List<IHaventForgottenInterfacesCanExtendOthers> - a List<Object> - a List<I'm probably forgetting some possibilities> And you have no way of knowing which it is. So yes, it's a boundary, which is significantly more than nothing. But far less useful than it feels like at first.

Gibbon1 9y ago

One the way to looking at other things(tm) I found a blog post by a CS language researcher talking about type erasure. His two points. Being able to do type erasure is great because it means your language is coherent. (Don't need to do any nasty kluges in the run time) And then everyone ratfucks themselves by actually implementing type erasure, and now your language will never have good tooling and thus will die a lonely unmourned death. He commented that C/C++ has type erasure and it's also a massive kludge (via the elf format). No one will invest that much effort into a new language. tl;dr: Type erasure, it's great, don't do it.

eeperson 9y ago
What tooling do you think is missing due to erasure?
- Gibbon1 9y ago
  Not a CS person, but I think if you keep the type information pined to the object in memory then a debugger can use the object type information in memory to match it with the object's definition in the program. That makes creating a debugger easy. Imagine wanting to know what the object at address 0x34199920 is. If you have type info[1] you can cross reference the type info with 'generic array' and then do the same with element 2, address 0x34199920 and know it's a 'foo object'. [1] Say the first 4 bytes is _always_ a type index that the compiler or interpreter generates.

cm2187 9y ago

But then what is the difference between a a collection of type object and a errasure model generic collection?

kelnos 9y ago
At the VM/bytecode level, not much (if anything?). The benefit comes at compile-time, where the compiler can verify that you're putting the correct types into a collection, and that you're expecting the correct types out.
- SideburnsOfDoom 9y ago
  > At the VM/bytecode level, not much (if anything?). I don't think this is correct. In C# code at runtime, and in the bytecode, you can inspect types for metadata about their generic type params. It is present in the .Net bytecode. See https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-and-reflection https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... > When a generic type or method is compiled into (bytecode), it contains metadata that identifies it as having type parameters. from https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-in-the-run-time https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
  - cm2187 9y ago
    But C# generics aren't erasure model collections are they?
    - SideburnsOfDoom 9y ago
      No, they are not. The point is, it is different at the bytecode level.
- shellac 9y ago
  You've got that completely the wrong way around. An erasing compiler has full access to the type (obviously - it's doing the erasing) and so can verify whether you're putting the correct types in or out of a collection. Where erasure can cause issues is at runtime. For example: X isa List<Int> Even if X is indeed a list of ints that information isn't held at runtime, so the test can't be supported. Having said that in some respects this is a C# / Java ecumenical matter. Haskell, for example, doesn't bake types into output code so I suppose it erases even more that java, but it supports very rich polymorphic behaviour.