【正文】 the creation of the @Override annotation in Java 5.) Notice, as well, that the return type is not specified it39。s obvious from the definition of the method body and that the returned value isn39。t explicitly denoted using the return keyword, which Java would require. Instead, the last value in the function is considered the return value implicitly. (You can always use return keyword if you prefer Java syntax, however.) Some core values Next up are the definitions of numer and denom, respectively. The syntax involved, offhand, would lead the Java programmer to believe that numer and denom are public Int fields that are initialized to the value of noverg and doverg, respectively。 but this assumption is incorrect. Formally, Scala calls numer and denom methods without parameters, which are used to create a quickandeasy syntax for defining accessors. The Rational class still has three private fields, n, d, and g, but they are hidden from the world by default private access in the case of n and d, and by explicit private access in the case of g. The Java programmer in you is probably asking at this point, Where are the corresponding setters for n and d? No such setters exist. Part of the power of Scala is that it encourages developers to create immutable objects by default. Granted, syntax is available to create methods for modifying the internals of Rational, but doing so would ruin the implicit threadsafe nature of this class. As a result, at least for this example, I39。m going to leave Rational as it is. Naturally, that raises the question of how one manipulates a Rational. Like , you can39。t take an existing Rational and modify its values, so the only alternative is to create new Rationals out of the values of an existing one, or create it from scratch. This brings into focus the next set of four methods: the curiously named +, , *, and / methods. And no, contrary to what it might look like, this isn39。t operatoroverloading. Operator, ring me a number 5 Remember that in Scala everything is an object. In the last article, you saw how that principle applies to the idea that functions themselves are objects, which allows Scala programmers to assign functions to variables, pass functions as object parameters, and so on. An equally important principle is that everything is a function。 that is to say, in this particular case, there is no distinction between a function named add and a function named +. In Scala, all operators are functions on a class. They just happen to have, well, funky names. In the Rational class, then, four operations have been defined for rational numbers. These are the canonical, mathematical operations add, subtract, multiply, and divide. Each of these is named by its mathematical symbol: +, , *, and /. Notice, however, that each of these operators works by constructing a new Rational object each time. Again, this is very similar to how works, and it is the default implementation because it yields threadsafe code. (If no shared state and internal state of an object shared across threads is implicitly shared state is modified by a thread, then there is no concern over concurrent access to that state.) What39。s new with you? The everything is a function rule has two powerful effects: The first, as you39。ve already seen, is that functions can be manipulated and stored as objects themselves. This leads to powerful reuse scenarios like the one explored in the first article in this series. The second effect is that there is no special distinction between the operators that the Scalalanguage designers might think to provide and the operators that Scala programmers think should be provided. For example, let39。s assume for a moment that it makes sense to provide an inversion operator, which will flip the numerator and denominator and return a new Rational (so that Rational(2,5) will return Rational(5,2)). If you decide that the ~ symbol best represents this concept, then you can define a new method using that as a name, and it will behave just as any other operator would in Java code, as shown in Listing 5: Listing 5. Let39。s flip val r6 = ~r1 (r6) // should print [3 / 1], since r1 = [1 / 3] Defining this unary operator in Scala is slightly tricky, but it39。s purely a syntactic nit: Listing 6. This is how you flip class Rational(n:Int, d:Int) { 6 // ... as before ... def unary_~ : Rational = new Rational(denom, numer) } The tricky part is, of course, the fact that you have to prefix the ~ name with unary_ to tell the Scala piler that it is intended to be a unary operator。 therefore, the syntax will be flipped from the traditional referencethenmethod syntax mon in most object languages. Note that this bines with the everything is an object rule to create some powerful but easytoexplain code opportunities: Listing 7. Add it up 1 + 2 + 3 // same as 1.+(2.+(3)) r1 + r2 + r3 // same as r1.+(r2.+(r3)) Naturally, the Scala piler does the right thing for the straight integer addition examples, but syntactically it39。s all the same. This means that you can develop types that are no different from the builtin types that e as part of the Scala language. The Scala piler will even try to infer some meaning out of the operators that have some predetermined meaning, such as the += operator. Note how the following code just does what it should, despite the fact that the Rational class doesn39。t have an explicit definition for +=: Listing 8. Scala infers var r5 = new Rational(3,4) r5 += r1 (r5) When printed, r5 has the value [13 / 12], which is exactly what it should be. Scala under the hood Remember that Scala piles to Java bytecode, meaning that it runs on the JVM. If you need proof, look no further than the fact that