Sorry for the list spam, but one more quick thought.... some of this might
be a perfect candidate for T4 code generation templates. I've had some
experience using and writing them, and have found it to be a fantastic tool
in certain instances. Of course, I believe T4 was only available in VS
2008+, so if we continue to maintain VS 2005 compatibility, we wouldn't be
able to make use of T4.
Allright... I'll shut up now. :)
Peter Mateja
peter.mat...@gmail.com
On Thu, Nov 11, 2010 at 12:58 PM, Peter Mateja <peter.mat...@gmail.com>wrote:
> Just a quick follow up on my IDisposable example. This immediately
> provides IDisposable functionality to all concrete implementations of
> Directory. However, in order to be correct, we'd need to make sure that
> finalizers were properly implemented in subclasses... e.g.
>
> public class FSDirectory : Directory
> {
> ...
> }
>
> should be:
> public partial class FSDirectory : Directory
> {
> ...
> }
>
> and in a separate file:
> public partial class FSDirectory
> {
> ~FSDirectory()
> {
> Dispose(false);
> }
> }
>
> That's pretty boilerplate, of course... but we also have the ability to
> provide additional functionality by overriding the Dispose(bool) protected
> method.
>
> Peter Mateja
> peter.mat...@gmail.com
>
>
>
> On Thu, Nov 11, 2010 at 12:51 PM, Peter Mateja <peter.mat...@gmail.com>wrote:
>
>> I think extension methods will be a great tool to supplement functionality
>> onto existing Lucene.Net base classes. However, in some cases I think
>> partial classes will be more effective. Using partial classes, you can
>> actually add additional interfaces to an existing class, something which
>> extensions methods won't provide (they only allow you to quack like a
>> duck... not actually be an IDuck).
>>
>> For example, many have requested that some of the core resource classes
>> implement IDisposable in order to support the using () {} construct. Using
>> partial classes, we can maintain the IDisposable implementation separately
>> from the core converted class, as long as part of the automated conversion
>> process marks the class as partial.
>>
>> Consider the current Directory class:
>> [Serializable]
>> public abstract class Directory
>> {
>> ...
>> }
>>
>> By simply making this a partial class, we'd be able to do the following:
>> [Serializable]
>> public abstract partial class Directory
>> {
>> ...
>> }
>>
>> in a separate file:
>> public partial class Directory : IDisposable
>> {
>> #region Implementation of IDisposable
>> private bool disposed=false;
>>
>> public void Dispose()
>> {
>> Dispose(true);
>> GC.SuppressFinalize(this);
>> }
>>
>> ~Directory()
>> {
>> Dispose(false);
>> }
>>
>> protected virtual void Dispose(bool disposeManagedResources)
>> {
>> if (!this.disposed)
>> {
>> if (disposeManagedResources)
>> {
>> this.Close();
>> }
>> }
>>
>> disposed=true;
>> }
>>
>> #endregion
>> }
>>
>> Peter Mateja
>> peter.mat...@gmail.com
>>
>>
>>
>> On Thu, Nov 11, 2010 at 12:27 PM, Alex Thompson
>> <pierogi...@hotmail.com>wrote:
>>
>>> I think a better pattern than partial classes would be extension methods
>>> (like the way LINQ works with IEnumerable). That way the extensions could
>>> be
>>> in a separate assembly but appear seamless with the core class.
>>>
>>> I don't like the name Lucere. I think it's too close and will create
>>> confusion. It's so close I wonder if the ASF will have something to say
>>> about it.
>>>
>>>
>>> -----Original Message-----
>>> From: Prescott Nasser [mailto:geobmx...@hotmail.com]
>>> Sent: Thursday, November 11, 2010 9:46 AM
>>> To: lucene-net-...@lucene.apache.org
>>> Subject: Re: Lucere project announcement
>>>
>>> There is benefit to making partial classes if we want to extend, but that
>>> adds complexity to the conversion and doesn't do one thing to help us get
>>> Lucene.Net into more native .net constructs
>>>
>>> I personally don't even know enough about lucene yet to know where people
>>> would want to extend it.
>>>
>>> Partial classes I think will be a good move once we have a good system in
>>> place to convert java to .net and show that we are keeping pace
>>> -----Original Message-----
>>> From: Peter Mateja <peter.mat...@gmail.com>
>>> Date: Thu, 11 Nov 2010 17:20:04
>>> To: <lucene-net-...@lucene.apache.org>
>>> Subject: Re: Lucere project announcement
>>>
>>> I'm a bit concerned that there's going to be a fragmentation of effort
>>> surrounding Lucene.Net, Lucere, and Aimee, LINQ to Lucene (
>>> http://linqtolucene.codeplex.com/, though this appears to be dead)
>>> causing
>>> more confusion than not. I do agree that initially, Lucene.Net should
>>> remain a line by line port. As much as the Java idioms pulled into
>>> Lucene.Net can be frustrating to work with in the context of standard
>>> .Net
>>> development, I think it's more important to have something that works
>>> now,
>>> and works exactly the same as the base Lucene. As discussed ad nauseum
>>> in
>>> other forums this has several key benefits.
>>>
>>> That said, I do long for the elegance of recent .Net language constructs
>>> and
>>> framework features. I've heard discussion of trying to build a .Net
>>> "layer"
>>> on top of Lucene.Net. Having dug into the Lucene.Net code a bit, I'd
>>> have
>>> to say that this will not be an easy task. I'd wager that quite a bit of
>>> the desired .Net-ification of Lucene.Net will result from better
>>> automated
>>> conversion methods, which would really hinge on the direction taken by
>>> the
>>> Lucene.Net project, not Lucere.
>>>
>>> One interesting direction to take, might be to transition some of the
>>> core
>>> classes in Lucene.Net into partial classes, allowing additional
>>> additional
>>> class tooling outside of the Lucene.Net core project. This is perhaps a
>>> naive suggestion, so if anyone has already considered this route, let me
>>> know.
>>>
>>> Peter Mateja
>>> peter.mat...@gmail.com
>>>
>>>
>>> On Thu, Nov 11, 2010 at 3:33 AM, Troy Howard <thowar...@gmail.com>
>>> wrote:
>>>
>>> > All,
>>> >
>>> > The recent discussions on this mailing list have shown a few things to
>>> > be
>>> > true:
>>> >
>>> > - Lucene.Net is definitely still a thriving project with strong
>>> >leadership represented by George and DIGY
>>> > - The community surrounding the project is vocal, vibrant and filled
>>> >with ideas and motivation to help
>>> > - There is a strong interest in seeing Lucene.Net continue as a
>>> >line-by-line port of Java Lucene:
>>> > - It's faster and more manageable to make releases because code can
>>> >be automatically converted
>>> > - Retains all the excellence of the Java Lucene project
>>> > - Provides end users with a wealth of existing knowledge and support
>>> >surrounding the Java Lucene project
>>> > - There is a strong interest in have a more ".Net style" port of
>>> >Lucene
>>> > - Many users feel using the Java-idiomatic API is unwieldy
>>> > - There is a desire to see the code take advantage of valuable .Net
>>> >framework features that do not exist in Java
>>> > - Performance can be improve on the .NET runtime by refactoring
>>> >
>>> > I'm very glad to see George has picked up the ball to keep Lucene.Net
>>> > going and applaud his commitment to keeping the project focused on
>>> > it's stated goals: a line-by-line port of Java Lucene that releases in
>>> > sync the main project.
>>> >
>>> > I'm also glad to see that a number of people have started contributing
>>> > in meaningful ways to the Lucene.Net project, working through the
>>> > action list George posted a few days ago. I would like to
>>> > optimistically think that crisis is well on it's way to being averted.
>>> >
>>> > I think this is a good sign that Lucene.Net will remain a vital and
>>> > active project as part of the ASF.
>>> >
>>> > With that said, I'd like to announce Lucere, a new Lucene-based .NET
>>> > project.
>>> >
>>> > The goal of Lucere is to create a "conceptual port" of Lucene for .NET
>>> > as contrasted with the current "syntactic port" approach taken by
>>> > Lucene.Net. We will start by creating a ground-up re-write of the
>>> > current feature set of Java Lucene 3.0.2 that is optimized for .NET.
>>> > This is a non-trivial task and may cause our initial release cycle to
>>> > be slow. Beyond that we will be spending a certain amount of time
>>> > upfront to design the API and architecture. While building our initial
>>> > architecture and design we want to take into consideration the many
>>> > different ideas that our community has to offer, producing what will
>>> > hopefully be a full featured, flexible library that integrates well
>>> > into a variety of kinds of applications.
>>> >
>>> > For more information, please see the project site at:
>>> >
>>> > http://lucere.codeplex.com
>>> >
>>> > We hope that the next few weeks will represent a lively discussion
>>> > from members of the Lucene.Net community about the idea of a new
>>> > project, our goals and the design and architecture of Lucere. In order
>>> > to keep discussion focused for both projects, please consider joining
>>> > the Lucere mailing list by sending a quick email to:
>>> >
>>> > lucere+subscr...@googlegroups.com<lucere%2bsubscr...@googlegroups.com>
>>> > lucere+<lucere%2bsubscr...@googlegroups.com<lucere%252bsubscr...@googlegroups.com>
>>> >
>>> >
>>> > Or, if you'd rather not use email, feel free to visit the discussion
>>> > forums on the project site at:
>>> >
>>> > http://lucere.codeplex.com/discussions
>>> >
>>> > Hopefully there's enough interest in both concepts such that both
>>> > projects may continue to move forward and thrive. We fully intend to
>>> > have our cake and eat it too. :)
>>> >
>>> > Thanks,
>>> > Troy
>>> >
>>>
>>>
>>
>
