Michael,
Sorry for the newb question, but what are the issues in moving to .NET
3.5
now (I just joined the list today and am looking around in the archives now,
btw)?
In the move from .NET 2.0 -> 3.5, the CLR was not changed. The only
things
that were changed were BCL types (base class libraries, and they are backwards
compatable), and the compilers (to allow for lambda expressions, anonymous
types, query syntax, and the like).
The reason I ask is that in doing my own port of Lucene.NET 2.0 to a
.NET 3.5
implementation, I've found that there are a number of helpful constructs, some
of them being:
- Hashset<T>
- LINQ allows for the flattening of a number of nasty embedded loops,
and a
more declarative style of code.
- Lambda expressions
Among many others.
If the concern is alienating a user base that is on .NET 2.0 and can't
move
to .NET 3.5, then that settles it, but if it is a concern over one of the
items mentioned above (changes in the CLR, BCL), then I'm not sure what the
concern is (not saying that there isn't one, but looking through the archives,
I can't find the particular discussion around this topic).
The reason I question this is because when working on my port, I
figured it
would be better to just contribute to the project itself. However, I feel I
can be of more use in getting the internals correct, and .NET 3.5 would really
help with that (there are a number of issues revolving around synchronization,
enumeration usage which are not best practices). While internals can be
changed for a move to .NET 2.0, for a lot of the places where you are going to
integrate .NET 2.0 code, you are probably going to want to use .NET 3.5 code
to even further simplify and enhance the code.
A perfect example is a number of the loop iterators that you have now
over
ArrayList instances. At the least, those instances should be strongly-typed
IList<T> implementations (typically List<T>) especially when the type
parameter T is a value type. When a value type, the performance of using an
IList<T> implementation over an ArrayList is somewhere around 40%-50% faster
than using ArrayList (because of lack of boxing). When a reference type,
there is still a performance gain (I think it was around 10%-20%, but don't
quote me on that one). This is all Generics, and I assume everyone knows the
benefits of moving to them.
When doing so, that causes a chain reaction. In moving to an IList<T>
implementation, you have an IEnumerable<T> implementation and you will want to
replace a lot of the iterator code from for loops to foreach loops (which you
can use in .NET 1.1, I don't know why they weren't used, you still had the
runtime cast issues).
However, most of these loops have some sort of
filtering/sorting/grouping
logic. LINQ really goes a great way to simplify the code in this situation,
separating the logic of what you want to do from the items you want to do it
to (or even creating the appropriate projections to assist in what you are
trying to do, I've used it in a number of places to flatten some pretty nasty
embedded for loops quite efficiently).
The point is, if you go to .NET 2.0, you get yourself part of the way
there
when it comes to how much you can do to improve the codebase (and I am
speaking only of the internal implementation, I'm not suggesting you change
the public definition of the class) and will eventually require a revisit to
the same code.
Given that you have the test cases already, what's the harm (assuming
it
isn't a user base issue) in going to .NET 3.5 now, and reaping the benefits
now if a number of files are going to be touched because of the move to .NET
2.0 anyways? - Nick
-----Original Message-----
From: Michael Garski [mailto:mgar...@myspace-inc.com]
Sent: Monday, November 09, 2009 11:20 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: 2.9 Target Framework
No problem - 2.0 it is.
Michael
-----Original Message-----
From: George Aroush [mailto:geo...@aroush.net]
Sent: Monday, November 09, 2009 7:16 PM
To: lucene-net-user@incubator.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: RE: 2.9 Target Framework
I agree with DIGY. We have discussed this in the past few times. We have
to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than
just port over logic from Java to C# -- but also take advantage of what C#
and .NET has to offer.
BTW, those kind of discussions should be on the dev side vs. user.
-- George
-----Original Message-----
From: Digy [mailto:digyd...@gmail.com]
Sent: Monday, November 09, 2009 1:19 PM
To: lucene-net-user@incubator.apache.org
Subject: RE: 2.9 Target Framework
I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good
place to switch to .NET 3.5 (so will Lucene.Java do also).
There are also a lot of places where smarter codes can be used ( replacing
"GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead
of using Hashtable etc.) But it can be a problem in porting unless we catch
up with Lucene.Java.
DIGY
-----Original Message-----
From: Michael Garski [mailto:mgar...@myspace-inc.com]
Sent: Monday, November 09, 2009 7:26 PM
To: lucene-net-...@incubator.apache.org;
lucene-net-user@incubator.apache.org
Subject: 2.9 Target Framework
Apologies for the cross-posting to both lists, but I think this issue is
applicable to both.
What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but
would like to ensure this is defined. There are a few cases in some of
the internal implementation where use of LINQ would be handy, such as in
collection transformations to arrays. Overall, it's not a big deal to
target 2.0 however some of the implementation will be a bit more elegant
and precise if we target 3.5.
Cheers,
Michael
Michael Garski
Sr. Search Architect
310.969.7435 (office)
310.251.6355 (mobile)
www.myspace.com/michaelgarski
smime.p7s
Description: S/MIME cryptographic signature
