>"Daniel John Debrunner" wrote: >Operators and self >It seems the operator methods should almost always be acting on thier own value, e.g. the plus() method should only >take one input and the result is the value of the receiver (self) added to the input. Currently the plus takes two inputs >and probably in most if not all cases the left input is the receiver. The result would be smaller code and possible >faster, as the method calls on self would not be through an interface.
The 'accumulate' method in SumAggregator calls the NumberDataValue 'plus' method. Naturally, since this call was the first one I looked at it passes 'self' as the 2nd addend but it does act on its own value and replaces its 'value' with the result. Accumulate checks itself for 'null' on every call and clones the 'addend' parameter if needed. Thus for an accumulation of 1 million rows it will check itself for 'null' 1 million times. If it were possible to always initialize the aggregator at creation this null check could be removed. AvgAggregator (via it's own accumulate method) is one user of the 'accumulate' method in SumAggregator. The accumulate method used in this class catches the 'value out of range' exception and promotes its 'value' to a class that can handle larger values; it then calls 'super.accumulate' (SumAggregator). So it appears that the 'result' parameter that SumAggregator's accumulate method passes on to the SQLInteger.plus method may 'morph' from a tiny or small int to an integer to a long to a big decimal. Thus for this use of 'plus' it doesn't appear that the result is necessarily the same class as the addend parameters. I may have missed something in the way that polymorphism may take care of this. There is also a comment by Dan in the AvgAggregator accumulate method: // this code creates data type objects directly, it is anticipating // the time they move into the defined api of the type system. (djd). Maybe Dan can comment on what this means.
