yeah about 5 seconds in I saw that and decided to stick with what I know :)
On Mon, Jun 15, 2009 at 5:10 PM, Mark Miller<markrmil...@gmail.com> wrote: > I may do the Highlighter. Its annoying though - I'll have to break back > compat because Token is part of the public API (Fragmenter, etc). > > Robert Muir wrote: >> >> Michael OK, I plan on adding some tests for the analyzers that don't have >> any. >> >> I didn't try to migrate things such as highlighter, which are >> definitely just as important, only because I'm not familiar with that >> territory. >> >> But I think I can figure out what the various language analyzers are >> trying to do and add tests / convert the remaining ones. >> >> On Mon, Jun 15, 2009 at 4:42 PM, Michael Busch<busch...@gmail.com> wrote: >> >>> >>> I agree. It's my fault, the task of changing the contribs (LUCENE-1460) >>> is >>> assigned to me for a while now - I just haven't found the time to do it >>> yet. >>> >>> It's great that you started the work on that! I'll try to review the >>> patch >>> in the next couple of days and help with fixing the remaining ones. I'd >>> like >>> to get the AttributeSource improvements patch out first. I'll try that >>> tonight. >>> >>> Michael >>> >>> On 6/15/09 1:35 PM, Robert Muir wrote: >>> >>> Michael, again I am terrible with such things myself... >>> >>> Personally I am impressed that you have the back compat, even if you >>> don't change any code at all I think some reformatting of javadocs >>> might make the situation a lot friendlier. I just listed everything >>> that came to my mind immediately. >>> >>> I guess I will also mention that one of the reasons I might not use >>> the new API is that since all filters, etc on the same chain must use >>> the same API, its discouraging if all the contrib stuff doesn't >>> support the new API, it makes me want to just stick with the old so >>> everything will work. So I think contribs being on the new API is >>> really important otherwise no one will want to use it. >>> >>> On Mon, Jun 15, 2009 at 4:21 PM, Michael Busch<busch...@gmail.com> wrote: >>> >>> >>> This is excellent feedback, Robert! >>> >>> I agree this is confusing; especially having a deprecated API and only a >>> experimental one that replaces the old one. We need to change that. >>> 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. >>> >>> However, we need to make the decisions: >>> a) if we want to release this new API with 2.9, >>> b) if yes to a), if we want to remove the old API in 3.0? >>> >>> If yes to a) and no to b), then we'll have to support both APIs for a >>> presumably very long time, so we then need to have a better solution for >>> the >>> backwards-compatibility here. >>> >>> -Michael >>> >>> On 6/15/09 1:09 PM, Robert Muir wrote: >>> >>> let me try some slightly more constructive feedback: >>> >>> new user looks at TokenStream javadocs: >>> >>> http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc/org/apache/lucene/analysis/TokenStream.html >>> immediately they see deprecated, text in red with the words >>> "experimental", warnings in bold, the whole thing is scary! >>> due to the use of 'e.g.' the javadoc for .incrementToken() is cut off >>> in a bad way, and its probably the most important method to a new >>> user! >>> there's also a stray bold tag gone haywire somewhere, possibly >>> .incrementToken() >>> >>> from a technical perspective, the documentation is excellent! but for >>> a new user unfamiliar with lucene, its unclear exactly what steps to >>> take: use the scary red experimental api or the old deprecated one? >>> >>> theres also some fairly advanced stuff such as .captureState and >>> .restoreState that might be better in a different place. >>> >>> finally, the .setUseNewAPI() and .setUseNewAPIDefault() are confusing >>> [one is static, one is not], especially because it states all streams >>> and filters in one chain must use the same API, is there a way to >>> simplify this? >>> >>> i'm really terrible with javadocs myself, but perhaps we can come up >>> with a way to improve the presentation... maybe that will make the >>> difference. >>> >>> On Mon, Jun 15, 2009 at 3:45 PM, Robert Muir<rcm...@gmail.com> wrote: >>> >>> >>> Mark, I'll see if I can get tests produced for some of those analyzers. >>> >>> as a new user of the new api myself, I think I can safely say the most >>> confusing thing about it is having the old deprecated API mixed in the >>> javadocs with it :) >>> >>> On Mon, Jun 15, 2009 at 2:53 PM, Mark Miller<markrmil...@gmail.com> >>> wrote: >>> >>> >>> Robert Muir wrote: >>> >>> >>> Mark, I created an issue for this. >>> >>> >>> >>> Thanks Robert, great idea. >>> >>> >>> I just think you know, converting an analyzer to the new api is really >>> not that bad. >>> >>> >>> >>> I don't either. I'm really just complaining about the initial >>> readability. >>> Once you know whats up, its not too much different. I just have found >>> myself >>> having to refigure out whats up (a short task to be sure) over again >>> after I >>> leave it for a while. With the old one, everything was just kind of >>> immediately self evident. >>> >>> That makes me think new users might be a little more confused when they >>> first meet again. I'm not a new user though, so its only a guess really. >>> >>> >>> reverse engineering what one of them does is not necessarily obvious, >>> and is completely unrelated but necessary if they are to be migrated. >>> >>> I'd be willing to assist with some of this but I don't want to really >>> work the issue if its gonna be a waste of time at the end of the >>> day... >>> >>> >>> >>> The chances of this issue being fully reverted are so remote that I >>> really >>> wouldnt let that stop you ... >>> >>> >>> On Mon, Jun 15, 2009 at 1:55 PM, Mark Miller<markrmil...@gmail.com> >>> wrote: >>> >>> >>> >>> Robert Muir wrote: >>> >>> >>> >>> As Lucene's contrib hasn't been fully converted either (and its been >>> quite >>> some time now), someone has probably heard that groan before. >>> >>> >>> >>> >>> hope this doesn't sound like a complaint, >>> >>> >>> >>> Complaints are fine in any case. Every now and then, it might cause a >>> little >>> rant from me or something, but please don't let that dissuade you :) >>> Who doesnt like to rant and rave now and then. As long as thoughts and >>> opinions are coming out in a non negative way (which certainly includes >>> complaints), >>> I think its all good. >>> >>> >>> >>> but in my opinion this is >>> because many do not have any tests. >>> I converted a few of these and its just grunt work but if there are no >>> tests, its impossible to verify the conversion is correct. >>> >>> >>> >>> >>> Thanks for pointing that out. We probably get lazy with tests, especially >>> in >>> contrib, and this brings up a good point - we should probably push >>> for tests or write them before committing more often. Sometimes I'm sure >>> it >>> just comes downto a tradeoff though - no resources at the time, >>> the class looked clear cut, and it was just contrib anyway. But then here >>> we >>> are ... a healthy dose of grunt work is bad enough when you have tests to >>> check it. >>> >>> -- >>> - Mark >>> >>> http://www.lucidimagination.com >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >>> >>> >>> >>> >>> >>> >>> >>> -- >>> - Mark >>> >>> http://www.lucidimagination.com >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >>> >>> >>> >>> >>> -- >>> Robert Muir >>> rcm...@gmail.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > -- > - Mark > > http://www.lucidimagination.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- Robert Muir rcm...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
