lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <s...@shadstorhaug.com>
Subject RE: Removing LuceneVersion.LUCENE_48 from external API?
Date Thu, 10 Nov 2016 07:32:44 GMT
I realize that - we wouldn't want to make them optional anyway because that would not be CLS
compliant (which we may never fully achieve, but should probably try to minimize the impact
for in case we eventually want to go there).

Besides, one of the "users" are the unit tests and they require the parameter to be there
in order to test the legacy code fully. Certainly the parameter will also be needed for those
who want to upgrade from 3.0.3 without changing their index format right away.

But I agree with you that the majority of the users could get a better experience if there
were overloads that didn't expect the LuceneVersion everywhere. 

But then, this really all depends on what the next planned version to port is. Imagine everyone
switched to this parameterless overload that defaulted to 4.8.0, then upgraded to 6.x with
the same index - they would need to touch every place in their code where the parameter is
missing and call the overload with 4.8.0 (assuming 6.x goes back at least 2 versions of backward
compatibility). The worst part is that since it is a piece of missing code, it would be impossible
to find all of those locations with a search, which would make the process very manual and
prone to error. Maybe it would be better to leave it alone...? Certainly, this is the reason
why using Version_Current is obsolete.

-----Original Message-----
From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar
Syn-Hershko
Sent: Thursday, November 10, 2016 2:12 PM
To: dev@lucenenet.apache.org
Subject: Re: Removing LuceneVersion.LUCENE_48 from external API?

Yes, but that essentially means changing them methods signatures since it's the first parameter
and default arguments need to be last


--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer
& Consultant Lucene.NET committer and PMC member

On Wed, Nov 9, 2016 at 11:07 PM, Shad Storhaug <shad@shadstorhaug.com>
wrote:

> Itamar,
>
> I think for those rare cases, we should leave it in. But, it would be 
> a good idea to add overloads that default them to the current version 
> so most users get a streamlined experience.
>
> You mentioned that you were "removing" them, I hope that you meant 
> that you are simply providing overloads that don't have them so they 
> are not required.
>
> Thanks,
> Shad Storhaug (NightOwl888)
>
> -----Original Message-----
> From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] 
> On Behalf Of Itamar Syn-Hershko
> Sent: Thursday, November 10, 2016 10:27 AM
> To: dev@lucenenet.apache.org
> Subject: Re: Removing LuceneVersion.LUCENE_48 from external API?
>
> It's a required argument for those methods - while I think it's too 
> verbose there as well, at least it makes sense because they have many 
> versions. We don't really need it because we only have one version, 
> except from the rare cases backwards supporting indexes that are 
> shared with Java code that maintains them.
>
> --
>
> Itamar Syn-Hershko
> http://code972.com | @synhershko <https://twitter.com/synhershko> 
> Freelance Developer & Consultant Lucene.NET committer and PMC member
>
> On Mon, Nov 7, 2016 at 6:02 AM, Wyatt Barnett 
> <wyatt.barnett@gmail.com>
> wrote:
>
> > I think making it an optional parameter sounds like a good idea on 
> > the surface. How does the java library handle this?
> >
> > On Thu, Nov 3, 2016 at 3:39 PM Itamar Syn-Hershko 
> > <itamar@code972.com>
> > wrote:
> >
> > > Hey folks,
> > >
> > > I'm working on some demos, and one things that keeps popping up 
> > > and to be frank gets quite annoying is the requirement to specify
> > > LuceneVersion.LUCENE_48 on all public APIs - opening a readers and
> > writers,
> > > analyzers, etc.
> > >
> > > Since we only have one version release, and that concept is not 
> > > going to
> > be
> > > really useful anyway, what do you say we remove (or set a default 
> > > value
> > for
> > > it) on all public facing APIs?
> > >
> > > Cheers,
> > >
> > > --
> > >
> > > Itamar Syn-Hershko
> > > http://code972.com | @synhershko <https://twitter.com/synhershko> 
> > > Freelance Developer & Consultant Lucene.NET committer and PMC 
> > > member
> > >
> >
>
Mime
View raw message