Hi Dan, Thanks for your feedback on this topic.
You asked "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?" I am not sure I understand the question. If you are asking without collation type changes, is the current CharTypeCompiler in Derby 10.3 have to support arbitrary comparable checks, then I don't know answer to it. It looks like from CharTypeCompiler.comparable() method implementation, that it definitely accepts all character types, date, time, timestamp, boolean and user types(which Derby does not support anymore). I was working on the mindset that we need to now have collation involved when TypeCompiler decides what the outcome of comparable should be. But current TypeCompiler does not have collation information. One alternative can be to store collation information in CharTypeCompiler and then comparable implementation in CharTypeCompiler can use collation in trying to decide outcome of comparable. I think what you are suggesting is to move comparable method out from the TypeCompiler and into DataTypeDescriptor altogether. So, the existing code, where we use TypeCompiler to decide if 2 types can be compared or not should now call a method on DTD to determine comparability. This might be cleaner than stuffing collation information in CharTypeCompiler but I am just wondering why was comparable not defined on DTD at the very start. Why do we go through TypeCompiler and what functionality does TypeCompiler provide that DTD does not? In other words, I don't understand the connection between TypeCompiler and DTD and how they fit together. thanks, Mamta On 4/18/07, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
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.
