On Mar 5, 2011, at 9:40 AM, Paul Elschot wrote: > Grant, > > I'm having a file system and/or hardware problem here, so I can only > comment by mail at the moment. > > The toString() implementations in (subclasses of) SrndQuery are supposed > to provide a mostly reparsable string, so it should be possible to use > that instead of passing in the original syntax string as in your patch. > I would run the existing tests with an extra println at a strategic point > to compare the parsed input to the toString() result, but I cannot do that > now... > > About the existing toString() implementations in the inner classes: as I > understand java's "qualified this" these should not need to be redirected > to the enclosing object for this issue. These existing toString()s were > only used for development, so I expect no problem in reimplementing them > in case this turns out to be necessary.
Right, I used the outer one, although I suspect it isn't correct yet, so will keep working on it. It's probably safest to look at the underlying structures that are used to create the query. > > Class objects should be unique, so I would expect the hashCode() and > equals() in my patch to work with them, but I could not yet find a > definite conclusion on inner classes in the java documentation. It could > be that the explicit "inner" classes in your patch work around that. What happens is that you actually end up comparing two different objects, one which is the DistanceQuery and one which is the inner class, so it doesn't work. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
