get rid of operators and the argument becomes moot. + is just another symbol for a method in that case. and for those that would complain about performance, lets not confuse representation (or the API) (ie the language) with implementation... 1 + 1 would still be compiled to a plus operator where as "a" + "b" would be compiled to StringBuilder... ooops, isn't that how it works already? My gosh, we do have operator overloading in Java.
Kirk On Aug 9, 2010, at 4:34 PM, Dick Wall wrote: > 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. > -- 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.
