On Monday, October 15, 2012 2:42:11 PM UTC+2, Simon Ochsenreither wrote: > > Unfortunately, introducing this kind of concept is exactly the kind of >> thing java does NOT do, and languages like Scala DO do: it's not a matter >> of superiority, it's a matter of tradeoffs: If this Nothing exists, it >> cannot actually be a subtype of Object; a List<?> cannot accept an instance >> of List<Nothing>, because I can still put nulls in List<?>, and nulls are >> not a valid value for Nothing. Hell, generics in general play havoc with >> this: Using trickery I can make a List<Nothing> with nulls in it, and then >> write return thisHackedList.get(0), which means in practice that Nothing >> needs type checking (i.e. that would lead to a ClassCastException or >> similar, even if .get(0) returns null). >> > > Is this just theorizing? I'd love to see that code. > > What code? It's trivial:
List<Nothing> list = new ArrayList<Nothing>(); list.add(null); //Barring compiler magic, this will compile and run without error. or: List<Object> list = new ArrayList<Object>(); list.add(null); List<Nothing> list2 = (List<Nothing>)list; Nothing aNothingVariableThatContainsValue = list2.get(0); // compiler or VM magic required to throw the needed runtime exception here. or even: Nothing y = null; // Compiler magic required to make this invalid. > >> That's the kind of thing where java has decided that the practical upside >> of having a 'Nothing' value is not actually that much; it's largely >> academic, and it definitely "feels bad" that the language is not complete, >> and that this awesome concept is not actually in your language. However, >> adding it to the language definitely incurs a cost: The compiler needs to >> do all sorts of things to treat Nothing specially, and this is going to >> make the spec much more complicated. >> > > Did you actually check that? Until now, I have only seen a Java-specific > issue which doesn't even exist in Scala. I'd love to see some of this > complexity caused by Nothing. > > Uh, no, it is common sense. See the above snippets. The compiler / runtime magic required to make nothing actually have its peculiar properties is not 'free' - it is a spec burden on the spec writers, it has real code and test that need to be written and maintained for the compiler and tool authors, and the programmers that write java need to know what it is (the mental burden). > > >> Scala-like design says you accept the complexity hit, and theorizes that >> if you go whole-hog on this you can actually remove a lot of complexity >> because the language is much more flexible. So far that seems like it's >> been working out reasonably well for scala. The java-like design says that >> these mostly academic features just aren't important enough, and in >> practice the language will be simpler if you just don't have them. Where >> people need them, they'll kludge it. >> > > Did you just make that up? > Mu; arguments are what they are. Your insinuation is a cheap tactic, though. > > > Sounds ugly. Yet, java's popularity and the robustness of java-based apps >> like google ads and many a server out there suggest it's fine. >> > > See the other recent debate. > 'the other recent debate'? - this forum has lots of threads. This thread has lots of posts. You're going to have to be more specific. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/f_aW4hUAeWwJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
