3 ms·

> How would you do this in a typesafe manner (i.e. "as" only works if Derived is actually inherited from Base) on JVM? On the JVM or in Java? In Java you don't

by pron 8y ago

> How would you do this in a typesafe manner (i.e. "as" only works if Derived is actually inherited from Base) on JVM? On the JVM or in Java? In Java you don't do it in such a safe manner. Whether you should or shouldn't be able to is another matter. If you want to write a JVM language where you want to do that safely (like Ceylon), you just reify your type -- at the cost of interop and reuse. Opting into reification is cheaper (at runtime) than opting out.

int_19h 8y ago
Let me rephrase that: how do you do it across languages? And why shouldn't you be able do it? Instantiations of generic interfaces are distinct types - the compile-time type system says so, and of course their members have different types too, so it can't possibly be a single type. So why can't you implement two different interface types on one class, just because they happen to be instantiations of the same generic? No matter how you slice it, it's an implementation restriction leaking out in a way that is inconsistent with the type system.
- pron 8y ago
  > how do you do it across languages? You don't. Haskell doesn't do it for its C calls. > And why shouldn't you be able do it? You are able to do it, but it comes at the cost of restricting your languages to the design of the runtime. It ends up being a question of which you prefer. Different languages that can freely share code and data, or languages that are either very restricted or require a lot of (runtime) effort to share code and data. > so it can't possibly be a single type List<String> and List<Integer> may be two different types in Java, but they're the same type in Clojure. Erasing generic types helps you enjoy both the type safety of Java and the flexibility of Clojure, at the tiny cost of some unsafe-ish reflective operations, out of many that are unsafeish anyway. > No matter how you slice it, it's an implementation restriction leaking out in a way that is inconsistent with the type system. It's not a restriction because a JVM language could choose to reify its generics, at the cost of foregoing efficient interop. It just so happens that most JVM languages choose not to do it that way.

by pron 8y ago

int_19h 8y ago

Let me rephrase that: how do you do it across languages? And why shouldn't you be able do it? Instantiations of generic interfaces are distinct types - the compile-time type system says so, and of course their members have different types too, so it can't possibly be a single type. So why can't you implement two different interface types on one class, just because they happen to be instantiations of the same generic? No matter how you slice it, it's an implementation restriction leaking out in a way that is inconsistent with the type system.

pron 8y ago
> how do you do it across languages? You don't. Haskell doesn't do it for its C calls. > And why shouldn't you be able do it? You are able to do it, but it comes at the cost of restricting your languages to the design of the runtime. It ends up being a question of which you prefer. Different languages that can freely share code and data, or languages that are either very restricted or require a lot of (runtime) effort to share code and data. > so it can't possibly be a single type List<String> and List<Integer> may be two different types in Java, but they're the same type in Clojure. Erasing generic types helps you enjoy both the type safety of Java and the flexibility of Clojure, at the tiny cost of some unsafe-ish reflective operations, out of many that are unsafeish anyway. > No matter how you slice it, it's an implementation restriction leaking out in a way that is inconsistent with the type system. It's not a restriction because a JVM language could choose to reify its generics, at the cost of foregoing efficient interop. It just so happens that most JVM languages choose not to do it that way.