Chris Holmes wrote: >> I would find it much more clear to make a class that does this in one >> pass; that is accepts a filter and outputs both an SQL statement and >> the leftover filter that could not be encoded. That way we do not >> split up decision making between two classes. > No, the reason we don't do that is because the encodings can be > different, indeed SQL is a misnomer. Not sure I followed you ... I am talking about the SQLEncoder taking on the job of splitting as well. > There are classes that 'do this in one pass', that make use of > SQLEncoder. But we don't combine splitting and encoding since > different classes do their encoding differently. I suppose you could > theoretically have the splitting in a super class that all inherit > from, but in my opinion it makes far more sense to have one class do > it and reuse that class. Different classes still do their encoding differently, they are also taking responsibility for building up the filter of things they could not encode.
Both solutions make sense; I just have a hard time debugging what went wrong with the current split then encode approach. Cheers, Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
