4 ms·

Could you explain that a little bit more? I'm using to Maybe from Haskell and am curious what might be missing from Java's Optional.

by tel 12y ago

deleted 12y ago
[deleted]
matwood 12y ago
Basically, because of type erasure you cannot have overloaded methods using different Optional types. So test(Optional<A> a); is the same method as test(Optional<B> b); I think you can define the types to get around it, but that is messy and a PITA. For example, class OptionalA extends Optional<A>.
- dignati 12y ago
  Wow that's a real pain point. Why would they even do that, is there a use case?
  - ZoFreX 12y ago
    Backward compatibility - you could run an application that uses generics, introduced in Java 1.5, on a Java 1.4 VM. At the time that was pretty amazing. These days, with so many backward compatibility-breaking changes being introduced, it doesn't feel so great.
    - deleted 12y ago
      [deleted]
    - mcculley 12y ago
      That was the original plan, but it never worked in my experience. The compiler as shipped required that -source 1.5 use -target 1.5. So hobbling the language this way served no benefit in the end.
  - im3w1l 12y ago
    In my opinion, no it really isn't. You can just create a method with a different name or a static constructing method if you need to overload constructors. The major pain point with generics is that they don't work with primitives.
  - tomp 12y ago
    Btw, type erasure is only a problem for Java because it supports runtime type information (which is incomplete, because of type erasure), and overloading (which I have no idea why the compiler can't handle). For languages like ML and Haskell, type erasure is no problem, because you can't access the types at runtime anyways.
- tel 12y ago
  That doesn't seem so bad to my eye, though. In Haskell terms it just means that any overloaded operators on Optional have to respect parametricity. If you need something more specifically typed then you can just use a new name. Is there a particular use case?
deleted 12y ago
[deleted]
im3w1l 12y ago
Because of type erasure, all Optional<T> are the same type at runtime, so Optional<Integer> can't be overloaded with Optional<Boolean>, because at runtime it will be impossible to tell which method should be caled.

Could you explain that a little bit more? I'm using to Maybe from Haskell and am curious what might be missing from Java's Optional.

by tel 12y ago

Could you explain that a little bit more? I'm using to Maybe from Haskell and am curious what might be missing from Java's Optional.

deleted 12y ago

[deleted]

matwood 12y ago

Basically, because of type erasure you cannot have overloaded methods using different Optional types. So test(Optional<A> a); is the same method as test(Optional<B> b); I think you can define the types to get around it, but that is messy and a PITA. For example, class OptionalA extends Optional<A>.

dignati 12y ago
Wow that's a real pain point. Why would they even do that, is there a use case?
- ZoFreX 12y ago
  Backward compatibility - you could run an application that uses generics, introduced in Java 1.5, on a Java 1.4 VM. At the time that was pretty amazing. These days, with so many backward compatibility-breaking changes being introduced, it doesn't feel so great.
  - deleted 12y ago
    [deleted]
  - mcculley 12y ago
    That was the original plan, but it never worked in my experience. The compiler as shipped required that -source 1.5 use -target 1.5. So hobbling the language this way served no benefit in the end.
- im3w1l 12y ago
  In my opinion, no it really isn't. You can just create a method with a different name or a static constructing method if you need to overload constructors. The major pain point with generics is that they don't work with primitives.
- tomp 12y ago
  Btw, type erasure is only a problem for Java because it supports runtime type information (which is incomplete, because of type erasure), and overloading (which I have no idea why the compiler can't handle). For languages like ML and Haskell, type erasure is no problem, because you can't access the types at runtime anyways.
tel 12y ago
That doesn't seem so bad to my eye, though. In Haskell terms it just means that any overloaded operators on Optional have to respect parametricity. If you need something more specifically typed then you can just use a new name. Is there a particular use case?

deleted 12y ago

[deleted]

im3w1l 12y ago

Because of type erasure, all Optional<T> are the same type at runtime, so Optional<Integer> can't be overloaded with Optional<Boolean>, because at runtime it will be impossible to tell which method should be caled.