You know - this argument gets rolled out every time operator overloading comes up, but I posit this simple counter argument:
In Java, you have to write .add, .multiply etc. methods (e.g. BigDecimal) because you can't overload the operators. This makes the code a heck of a lot messier but doesn't bring any extra safety - seriously what's the difference between overloading + with something inappropriate and overloading .plus or .add with something that removes or subtracts, especially because you can't use the operators on your own classes anyway. A badly named method is a liability whether it's symbolic or alphanumeric in nature. It all speaks to poor software engineering practices. Anything else is a smokescreen. This is why Scala does not have "operator overloading", it simply allows symbolic method names. 5 + 6 and 5 plus 6 can be equivalent, both mean something to the developer using the object, both could be abused. Dick On Aug 7, 3:32 pm, Reinier Zwitserloot <[email protected]> wrote: > How's that a case for simplicity for scala? > > In java, "5 + 2" means just what you think it means, intuitively. If > you want to know more still you'll have delve into the extensive JLS > which confirms your suspicions. > > In scala you need to delve into the libraries, and you really have no > idea what it could possibly do - every object can field its own > definition of '+'. This isn't simple anymore; the drive to libraryize > all complexity means that most seemingly atomic library operations are > in fact not the lowest layer, but they build on a lower layer still, > and in languages like scala, that lowest of layers is not all that > natural. > > I continue to assert that claiming scala is simpler because the JLS is > longer than the scala equivalent is the stupidest thing I've ever > heard. > > On Aug 6, 10:59 am, Kevin Wright <[email protected]> wrote: > > > > > 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 <[email protected]> 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 [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<javaposse%2bunsubscr...@googlegroups > > > .com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/javaposse?hl=en. > > > -- > > Kevin Wright > > > mail/google talk: [email protected] > > wave: [email protected] > > 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 [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.
