lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prescott Nasser <geobmx...@hotmail.com>
Subject RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
Date Thu, 29 Dec 2011 22:38:55 GMT
I dont think at the end of the day we want to make just cosmetic changes. We also have the
issue of same name different casing which needs to be fixed - but it's not clear how to manage
that without some large adjustments to the API.



Sent from my Windows Phone
________________________________
From: Troy Howard
Sent: 12/29/2011 2:19 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g

My vote goes to merging the two:

Apply the same concepts from 2.9.4g to 3.X development, using generics
where possible, Disposable vs Close, and exposing *additional* APIs
for generics (but leaving the existing old ones) to enable the
underlying performance improvements the generics offer. Also, expose
IEnumerable<T> implementations vs Java style enumerables/iterators.

If we are only adding to the existing and making relatively minor
changes to enable generics, updating/maintenance should be relatively
easy and it won't break anyone's code.

Thanks,
Troy


On Thu, Dec 29, 2011 at 2:08 PM, Prescott Nasser <geobmx540@hotmail.com> wrote:
> I agree its a matter of taste. I'd vote continue with g and evolve it to where we want
a .net version to be. What do others think?
>
> Sent from my Windows Phone
> ________________________________
> From: Digy
> Sent: 12/29/2011 1:16 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
>
> When I started that "g" branch, I had no intention to change the API, but at
> the end it resulted in a few changes
> like StopAnalyzer(List<string> stopWords),
> Query.ExtractTerms(ICollection<string>) etc.
> But I think, a drop-in replacement will work for most of the Lucene.Net
> users (Of course some contribs have been also modified accordingly)
>
> Changing arraylists/collections with generic counterparts, GetEnumerator's
> with foreach, AnonymousClass's with
> Func<> or Action<>'s and Fixing LUCENENET-172 are things most people would
> not notice.
>
> This "g" version includes also some other patches that were fixed for
> .GE.(=>) Lucene3.1 (Which? I have to rework on my commits)
>
> So, there isn't much change in API, more changes for developers and more
> stable code(At least I think so, since I use this "g" version in production
> env. for months without any problem. For short, 2.9.4g is a superset of
> 2.9.4 in bugfix level)
>
>
> As a result, creating a new branch for .Net friendly Lucene.Net or
> continuing on this branch is just a matter of taste.
>
> DIGY
>
>
>
>
>
>
> -----Original Message-----
> From: Scott Lombard [mailto:lombardenator@gmail.com]
> Sent: Thursday, December 29, 2011 5:05 PM
> To: lucene-net-dev@lucene.apache.org
> Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
>
>
> I don't see the g branch differing all that much from the line-by-line port.
> All the g branch does is change some data types as generics, but line by
> line the code the same once the generics are declared.
>
> I don't see 2.9.4g being any closer to a .NET style version than 2.9.4.
> While it does generics use for list style variable types the underlying
> classes are still the same and all of the problems with 2.9.4 not being .NET
> enough would be true in 2.9.4g.
>
> I would have to refer to Digy on if it changes how an end user interacts
> with Lucene.NET.  If it does not affect how the end user interacts with
> Lucene.NET then I think we should merge it into the Trunk and go from there
> on 3.0.3.
>
>
> Scott
>
>
>> -----Original Message-----
>> From: Prescott Nasser [mailto:geobmx540@hotmail.com]
>> Sent: Wednesday, December 28, 2011 8:28 PM
>> To: lucene-net-dev@lucene.apache.org
>> Subject: RE: [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g
>>
>>
>> Any reason we can't continue this g branch and make it more
>> and more .net like? I was thinking about what we've expressed
>> at goals - we want a line by line port - it's easy to
>> maintain parity with java and easy to compare. We also want a
>> more .NET version - the g branch gets this started - although
>> it's not as .Net as people want (I think).
>>
>>
>>
>> What if we used the g branch as our .Net version and
>> continued to make it more .Net like? and kept the trunk as
>> the line by line? The G branch seems like a good start to the
>> more .Net version anyway - we might as well build off of that?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------- > From:
>> digydigy@gmail.com > To: lucene-net-dev@lucene.apache.org >
>> Date: Thu, 29 Dec 2011 02:45:23 +0200 > Subject: RE:
>> [Lucene.Net] Lucene.Net 3 onwards and 2.9.4g > > > but I
>> guess the future of 2.9.4g depends on the extent that it is
>> becoming > more .NET like > > My intention while I was
>> creating that branch was just to make 2.9.4 a > little bit
>> more .Net like(+ maybe some performance). > I used many codes
>> from 3.0.3 Java. So it is somewhere between 2.9.4 & 3.0.3 >
>> But I didn't think it as a separate branch to evolve on its
>> own path. It > is(or I think it is) the final version of 2.9
>> > > DIGY > > -----Original Message----- > From: Christopher
>> Currens [mailto:currens.chris@gmail.com] > Sent: Wednesday,
>> December 28, 2011 9:20 PM > To:
>> lucene-net-dev@lucene.apache.org > Cc:
>> lucene-net-user@lucene.apache.org > Subject: Re: [Lucene.Net]
>> Lucene.Net 3 onwards and 2.9.4g > > One of the benefits of
>> moving forward with the conversion of the Java > Lucene, is
>> that they're using more recent versions of Java that support
>> > things like generics and enums, so the direct port is
>> getting more and more > like .NET, though not in all respects
>> of course. I'm of the mind, though, > that one of the larger
>> annoyances, Iterables, should be converted to > Enumerables
>> in the direct port. It makes it a pain to use it in .NET >
>> without it inheriting from IEnumerable, since it can't be
>> used in a foreach > loop or with linq. Also, since the direct
>> port isn't perfect anyway, it > seems a port of the IDEA of
>> iterating would be more in the spirit of what > we're trying
>> to accomplish, since the code would pretty much be the same,
>> > just with different method names. > > I sort of got off
>> topic there for a second, but I guess the future of > 2.9.4g
>> depends on the extent that it is becoming more .NET like. >
>> Obviously, while java is starting to use similar constructs
>> that we have > in .NET, it will never be perfect. Admittedly,
>> I haven't looked at 2.9.4g > in a little while, so I'm not
>> sure how much it now differs from 3.x, since > there's a
>> relatively large change there already. > > Thanks, >
>> Christopher > > On Thu, Dec 22, 2011 at 9:13 PM, Prescott
>> Nasser > wrote: > > > > > That's a great question - I know a
>> lot of people like the generics, and I > > don't really want
>> it to disappear. I'd like to keep it in parity with the > >
>> trunk. But I know we also have a goal of making Lucene.Net
>> more .Net like > > (further than 2.9.4g), and I don't know
>> how that fits in. We are a pretty > > small community and I
>> know everyone has some pretty busy schedules so it > > takes
>> us considerable time to make big progress. Trying to keep
>> three > > different code bases probably isn't the right way
>> to go. > > > > > > > > > Date: Fri, 23 Dec 2011 13:02:03
>> +1100 > > > From: mitiaguin@gmail.com > > > To:
>> lucene-net-user@lucene.apache.org > > > Subject: [Lucene.Net]
>> Lucene.Net 3 onwards and 2.9.4g > > > > > > I was browsing
>> "Roadmap" emails from November in Lucene developer list. > >
>> It > > > remains unclear in what state Lucene 3 porting is ,
>> but my question more > > > about 2.9.4g . > > > Is it kind of
>> experimental dead end variation of 2.9.4 with generics ? > Am
>> > > > I right in classifying it as more .Net like 2.9.4 which
>> is unrelated to > > > roadmap Lucene 3 porting effort. > >
>> ----- > > Checked by AVG - www.avg.com > Version: 2012.0.1901
>> / Virus Database: 2109/4708 - Release Date: 12/28/11 >
>>
>
> -----
>
> Checked by AVG - www.avg.com
> Version: 2012.0.1901 / Virus Database: 2109/4710 - Release Date: 12/29/11
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message