On Thursday, April 25, 2002, at 05:27 PM, Sam Joseph wrote: > Please find patch attached. Sorry about the corruption - my mailer > seems to be weirding out.
Sam, I've attached a revised patch. things I changed: * removed the new methods that parse strings into Criterions (prefer to keep this patch confined to fixing the precedence) * renamed types to conjunctions, including the getter. * changed clauses and conjunctions from Vectors to Lists with ArrayList implementations * made getClauses and getConjunctions private * removed the previous and and or fields and their getters (they had previously been commented out) * split a couple more long lines * removed x_ from a few variable names. I stopped short of committing this patch for the following reasons: I haven't analyzed the recursion in the appendTo methods to satisfy myself that they work correctly. And I also haven't analyzed the equals() and hashcode() methods either. They all look reasonable enough, but I just want to be careful. More importantly... Removing the getAnd and getOr methods is a change to the public API. They were public but disfunctional (in that they didn't allow a coherent precedence to be set). They probably should have been private. It seems fairly unlikely that there would be much code out there using those methods. Any objections to just removing them? Or do you prefer that they be deprecated? I know that Torque is in use in a few projects even though it hasn't been released. Because it hasn't been released I think we can remove these methods without violating the letter of the deprecation policy. But it is a violation of the spirit. Because these two methods would be mostly useless outside of Criteria, I would not object to bending the spirit of the deprecation policy in these specific cases. What say you? -Eric
Criteria.patch
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
