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.) -- 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/-/62RqvaKdS44J. 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.
