Overriding operators

1+1 is just a convenient way of writing 1.plus(1). This is achieved by class

Integer having an implementation of the plus method. This convenient feature is also available for other operators.

You can easily use any of these operators with your own classes. Just implement the respective method. Unlike in Java, there is no need to implement a specific interface.

Method-based operators

OperatorNameMethodWorks with
a + bPlusa.plus(b)Number, string, collection
a-bMinusa.minus(b)Number, string, collection
a*bStara.multiply(b)Number, string, collection
a/bDividea.div(b)Number
a%bModulea.mod(b)Integral number
a++Post incrementa.next()Number, string, range
++aPre increment
a–Post decrementa.previous()Number, string, range
–aPre decrement
a**bPowera.power(b)Number
a | bNumerical ora.or(b)Integral number
a & bNumerical anda.and(b)Integral number
a ^ bNumerical xora.xor(b)Integral number
~ aBitwise complimenta.negate()Integral number, string (the

latter returning a regular

expression pattern)

 

a [b]Subscripta.getAt(b)Object, list, map,

String

,

Array

 

a [b]=cSubscript assignmenta.putAt(b, c)Object, list, map,

StringBuffer

,

Array

 

a << bLeft shifta.leftShift(b)Integral number, also used like

“append” to

StringBuffers,

Writers, Files,

Sockets, Lists

a >>bRight shifta.rightShift(b)Integral number
a >>> bRight shift unsigneda.rightShiftUnsigned(b)Integral number
switch(a){

case b:

}

 

Classificationb.isCase(a)Object, range, list,

collection, pattern, closure;

also used with collection c in c.grep(b), which returns all items of c where b.isCase(item)

 

a==bEqualsa.equals(b)Object; consider

hashCode()

a

 

a !=bNot Equal! a.equals(b)Object
a <=> bSpaceshipa.compareTo(b)java.lang.Comparable
a > bGreater thana.compareTo(b) > 0
a >= bGreater than or equal toa.compareTo(b) >= 0
a < bLess thana.compareTo(b) < 0
a <= bLess than or equal toa.compareTo(b) <= 0
a as typeEnforced correctiona.asType(typeClass)Any type

This is all good in theory, but let’s see how they work in practice.

Overridden operators in action:

We implement equals such that it copes with null comparison. This is Groovy style. The default implementation of the equals operator doesn’t throw any NullPointerExceptions either. Remember that == (or equals) denotes object equality (equal values), not identity (same object instances).

Operator override

Bellow code demonstrates an implementation of the equals == and plus + operators for a Money class. We allow money of the same form of currency to be added up but do not support multicurrency addition.

We implement equals such that it copes with null comparison. This is Groovy style. The default implementation of the equals operator doesn’t throw any NullPointerExceptions either. Remember that == (or equals) denotes object equality (equal values), not identity (same object instances).

Code:

class Money {

            private int amount

            private String currency

            Money (amountValue, currencyValue) {

                        amount = amountValue

                        currency = currencyValue

            }

            boolean equals (Object other) {                                              (override == operator)

                        if (null == other) return false

                        if (! (other instanceof Money)) return false

                        if (currency != other.currency) return false

                        if (amount != other.amount) return false

                        return true

            }

            int hashCode() {

                        amount.hashCode() + currency.hashCode()

            }

            Money plus (Money other) {                                                    (implement + operator)

                        if (null == other) return null

                        if (other.currency != currency) {

                                    throw new IllegalArgumentException(

                                    "cannot add $other.currency to $currency")

                                    }

                        return new Money(amount + other.amount, currency)

                        }

            }

            def buck = new Money(1, 'USD')

            assert buck

            assert buck == new Money(1, 'USD')                                     (use overhidden ==)

            assert buck + buck == new Money(2, 'USD')                        (use overhidden +)

Overriding  equals is straightforward, as we show at override == operator. We also provide a hashCode method to make sure equal Money objects have the same hashcode. This is required by Java’s contract for java.lang.Object. The use of this operator is shown at use overhidden== where one dollar becomes equal to any other dollar.

At  Implement + operator, the plus operator is not overridden in the strict sense of the word, because there is no such operator in Money’s superclass (Object). In this case, operator implementing is the best wording. This is used at Use overhidden+, where we add two Money objects.

To explain the difference between overriding and overloading, here is a possible overload for Money’s plus operator. In case, we would like to add Money as

            assert buck + 1 == new Money(2, 'USD')

We can provide the additional method

  Money plus (Integer more) {

                        return new Money(amount + more, currency)

            }

that overloads the plus method with a second implementation that takes an Integer parameter. The Groovy method dispatch finds the right implementation at runtime.

This example leads to the general issue of how to deal with different parameter types when implementing an operator method.

Making coercion work for you:

Implementing operators is straightforward when both operands are of the same

type. Things get more complex with a mixture of types, say

            1 + 1.0

This adds an Integer and a BigDecimal. One of the two arguments needs to be promoted to the more general type. This is called coercion.

When implementing operators, there are three main issues to consider as part of coercion.

Supported argument types

You need to decide which argument types and values will be allowed. If an operator must take a potentially inappropriate type, throw an IllegalArgumentException where necessary. For instance, in our Money example, even though it makes sense to use Money as the parameter for the plus operator, we don’t allow different currencies to be added together.

Promoting more specific arguments

If the argument type is a more specific one than your own type, promote it to your type and return an object of  your type. To see what this means, consider how you might implement the plus operator if you were designing the BigDecimal class, and what you’d do for an Integer argument. Integer is more specific than BigDecimal: Every Integer value can be expressed as a BigDecimal, but the reverse isn’t true. So for the BigDecimal. plus(Integer)operator, we would consider promoting the Integer to BigDecimal,performing the addition, and then returning another BigDecimal even if the result could accurately be expressed as an Integer.

Handling more general arguments with double dispatch

f the argument type is more general, call its operator method with yourself (“this,” the current object) as an argument. This is also called double dispatch,and it helps to avoid duplicated, asymmetric, possibly inconsistent code. Let’s reverse our previous example and consider Integer.plus (BigDecimal operand). We would consider returning the result of the expression operand.plus(this), delegating the work to BigDecimal’s plus(Integer) method. The result would be a BigDecimal, which is reasonable—it would be odd for 1+1.5 to return an Integer but 1.5+1 to return a BigDecimal. Of course, this is only applicable for commutative operators.

Groovy’s conventional behavior

Groovy’s general strategy of coercion is to return the most general type. Other languages such as Ruby try to be smarter and return the least general type that can be used without losing information from range or precision. The Ruby way saves memory at the expense of processing time. It also requires that the language promote a type to a more general one when the operation would generate an overflow of that type’s range. Otherwise, intermediary results in a complex calculation could truncate the result.

By | 2017-07-21T21:41:26+00:00 December 25th, 2016|groovy|0 Comments

About the Author:

Leave A Comment