Quoting Pat Farrell (2018-10-26 21:30:47)
> This leads to my second issue with the OP's ideas. I strongly believe
> that Java has been damaged by its attempt to deliver backward
> compatability. While others have brought up the potential issues with
> keywords, a much more telling disaster was Java's implementation of
> generics. It was done in a language compatable way, but there result
> was design choices and restrictions that make it nearly impossible to
> use Java generics "properly". Lest you think I exaggerate, look at
> Exhibit 1, the FAQ on how to actually use it is huge. It has hundreds
> of edge cases. See
> FAQ.� http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
> If the implementation had decided to not require backwards
> compatibility, they might have been able to design generics such that
> there is no need for thousands of special case rules that are
> Frequently Asked.
Definitely worth nothing: there *pages* in that FAQ that could have been
cut if they'd just removed covariant array subtyping, to be consistent
with the rules for generics and (more importantly) actually sound.
For anyone who doesn't know what I'm talking about:
class Main {
public void main(String[] args) }
String[] strArray = new String[4];
// Arrays are references, so this points to the same
// memory:
Object[] objArray = strArray;
// Whoops, now there's an integer in your array of
// strings!
objArray[0] = new Integer(80);
}
}
This type-checks. It throws an ArrayStoreException at runtime. I do not
miss explaining ArrayStoreException to students.
It also seems like 25% of the FAQ amounts to "type erasure makes runtime
checks not work."
I don't know of any mistake in Go 1 that's quite as egregious while
being and quite as easily fixed -- but I agree we should keep our eyes
out for designs that are becoming far more complicated for the sake of
backwards compatibility.
---
It is also worth observing that the Java developers were attacking a
much harder problem in adding generics to Java that we are trying to add
them to Go -- subtyping and parametricity have very subtle interactions,
and finding satisfactory ways to mix them has been the subject of a lot
of type-theory research over the past few decades. Prior to the past
couple of years, I would have just advised someone designing a new
language to punt on one feature or the other entirely. I might still,
but there have been a few developments of late that that are
encouraging. Good luck bolting them on to an existing design though.
Happily, Go doesn't have subtyping in the first place.
(there are a few minor things that look like subtyping at first glance,
but I suspect they don't present a problem. It's hard to not be
a bit handwavy here since the language spec is not mathematically
precise wrt the type system).
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
