Just to put this into perspective for those who don't know the concepts: Bottom is the universal subtype, it's a subtype of EVERYTHING else in the type system, including primitives. It also only makes sense as a type, it's never actually possible to have an instance of Bottom. There's no way to directly express this in Java, but it's easy to give an example where it makes sense... What's the return type of a `throw new XXX` statement? Even if this occurs in a method declared as returning a primitive? The bottom type is also the correct return type of a method that only ever goes into an infinite loop.
Unit is the "I've returned, but without an information except the fact that I've returned" type. Void comes close, but (crucially) the Unit type is considered to have just the one value. Think of this as an immutable singleton being returned from every `void` method, if it helps. Void is what Java calls Unit when dealing with a void-returning method through reflection. It's not *quite* right though, as Void doesn't have that crucial singleton instance - which gives rise to the hack discussed so far in this thread. If anyone's interested, the bottom type in Scala is named `Nothing`, Unit is named `Unit`, and the unique instance of Unit is named `()`. So it *is* possible for these concepts to be represented in a way that compiles nicely down to JVM bytecode. On 8 October 2012 00:33, Simon Ochsenreither <simon.ochsenreit...@gmail.com>wrote: > I think it is an interesting example how some "pragmatic" and > superficially simpler approach tends to break down and cause complexity in > both the spec and the implementation compared to the "academic" solution. > > From a language design POV there are multiple issues here: > > - Primitive types vs. wrappers thing, which leads to really ugly > interactions > - Conflation of Void, Unit and Bottom > - Lack of pricinpal types for things like non-determination or null > > A neat thing is how one misfeature (null) is basically saving the > functionality of another feature. (See C# for a different, imho less nice > solution.) > > While I can see how the notion of "it doesn't return anything" for void > looks intuitive from a low-level point of view (nothing gets > push'ed/pop'ed), it is not intuitive if you view a program purely from an > data flow perspective, because there is a difference between "it returns, > but with no new information" and "it doesn't return" which Java completely > fails to capture. > > Additionally, the fact that void is not even a type, but some special, > hard-coded language keyword also adds complexity to the whole concept. > > (Some newer languages got all of this right from the start.) > > -- Kevin Wright mail: kevin.wri...@scalatechnology.com gtalk / msn : kev.lee.wri...@gmail.com quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda <kev.lee.wri...@gmail.com> twitter: @thecoda vibe / skype: kev.lee.wright steam: kev_lee_wright "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
