Mamta Satoor wrote:
This is the background information about how there are 2 different kinds of
methods in TC. One type that uses the TypeId associated with BTC to implement
the methods and the other type which ignore TypeId and just uses the passed
parameters to provide the method implementation.
What I am proposing is to change the comparable method from type 1 to type 2. The reason for this is comparable method for character types should also check the collation type and derivation while deciding whether the method should return true or false. But since the collation information is not associated with TypeId, we need to pass the TypeDescriptors of both the types that need to be compared. In order to do this, I propose the comparable method to change as follows
boolean comparable(
DataTypeDescriptor leftType,
DataTypeDescriptor rightType,
boolean forEquals,
ClassFactory cf);
"other type which ignore TypeId" -- This is a good indication in oo
programming that the method is defined on the wrong interface. That is,
if a method is defined to ignore the type is declared on then that's not
good oo style. In this instance (& I see from your post that the class
already has this problem) does the compare method on CharTypeCompiler
have to support arbitrary comparable checks, e.g. Blob against INTEGER?
In situations like this one can typically determine the correct
interface for the method declaration from the parameter types that are
used, e.g. in this case DataTypeDescriptor seems the logical choice.
The data type system is full of inconsistent methods, e.g. the add
method on DataValueDescriptor (DVD) is something like
DVD add (DVD left, DVD right, DVD result)
This indicates the actual instance the method is called upon has no
input on the result which is just not good. Alternate signatures that
make more sense would be:
// set result = this+other
void add(DVD other, DVD result)
// set this = left+right
void add(DVD left, DVD right)
This is actually more that just good style, the signature of this add
method (and other methods) has lead to a programming style that results
in extra checks and field assignments for every addition thus decreasing
performance. Either one of the alternate signatures would have avoided
those issues up front.
Dan.
