Eric Dobbs wrote: > 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)
Fair enough, they were just there for you to see them > * renamed types to conjunctions, including the getter. ok > * changed clauses and conjunctions from Vectors to > Lists with ArrayList implementations works for me > * made getClauses and getConjunctions private ditto > * removed the previous and and or fields and their > getters (they had previously been commented out) right > * split a couple more long lines always helpful > * removed x_ from a few variable names. Yes, I got a mail from Jon Scott Stevens about that. He helpfully pointed me at the coding conventions for turbine, which I hadn't seen yet. Will follow in future. you may want to remove o_ and p_ from some variable names as well, although I think they're swish :-) > 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. Sure. I have some test code for that. I extended the CriteriaTest object in the src/test/org/apaceh/torque/util/ directory Would you like a copy? Unfortunately it makes use of those parsing methods you removed. > 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. Sure > Any objections to just removing them? > Or do you prefer that they be deprecated? Deprecation would be safer no? I mean they could even be set up to return the first ANDed or ORed clause if one was present? > 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? I say fine, but I gues you're polling everyone rather than just me. CHEERS> SAM -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
