> And I don't like the *useNewAPI*() methods either. I spent a lot of time > thinking about backwards compatibility for this API. It's tricky to do > without sacrificing performance. In API patches I find myself spending > more time for backwards-compatibility than for the actual new feature! :( > > I'll try to think about how to simplify this confusing old/new API mix.
One solution to fix this useNewAPI problem would be to change the AttributeSource in a way, to return classes that implement interfaces (as you proposed some weeks ago). The good old Token class then do not need to be deprecated, it could simply implement all 4 interfaces. AttributeSource then must implement a registry, which classes implement which interfaces. So if somebody wants a TermAttribute, he always gets the Token. In all other cases, the default could be a *Impl default class. In this case, next() could simply return this Token (which is the all 4 attributes). The reuseableToken is simply thrown away in the deprecated API, the reuseable Token comes from the AttributeSource and is per-instance. Is this an idea? Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
