Re: Type system notes

>"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.