The idea that we can establish some sort of formal complexity measurement for documentation is... interesting. Although I think there's more joy to be had in measuring EBNF, or the size of some other parser grammar considered complete for the language.
I'd also like to briefly explore one of the differences between the two language specs... Consider the `+` operator. In the JLS, this is covered in chapter 15, "expressions" 15.18 - additive operators 15.18.1 - string concatenation 15.18.1.1 - string conversion 15.18.1.2 - optimization of string concatenation 15.18.1.3 - examples of string concatenation 15.18.2 - additive operators for numeric types Spanning pages 496-501 It's a bit different in Scala, which doesn't have operators as quite the same way. They're just methods in infix/operator notation. Everything in Scala is also an object (no primitives). Int, Float, String etc. are still optimised in the compiler, and will often use primitives in the generated bytecode, but within Scala code they are objects. So `+` becomes a method on the String/Int/Float/etc. object. The Scala spec doesn't list API methods any more than the JLS does. What the spec *does* have is section 6.12.3, outlining how methods used in the infix position have a precedence determined by the first character of the operator name. One beauty of thie approach is that it effectively gives you operator overloading, allowing things like this: http://www.scala-lang.org/api/current/scala/math/BigDecimal.html This is sufficient to be able to duplicate Java's behaviour, by building up to it on the basis of a broader (and simpler) concept. So "x" + 2 May look the same as Java, but it's actually achieved via the `+` method on a String instance, and not a dedicated special-case operator with 3 sections in the language spec. On 6 August 2010 00:38, JodaStephen <scolebou...@joda.org> wrote: > Kevin Wright is fond of repeating: > Java (3rd Edition): 649 pages, 7932 KB > Scala (current in trunk): 191 pages, 1312 KB > therefore Scala is less complex. > > But has anyone actually analysed the specs in detail? > > In code coverage terms, how many distinct "code paths" are there in > each spec. That is surely a far better measure than number of pages. > > Volunteers for counting?!! > > Stephen > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: kev.lee.wri...@gmail.com wave: kev.lee.wri...@googlewave.com skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@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.
