db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Changes to comparable method in TypeCompiler
Date Wed, 18 Apr 2007 20:43:51 GMT
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.




Mime
View raw message