lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Contrib/Spatial port
Date Tue, 22 Apr 2014 14:55:33 GMT
I'd actually say do go ahead and change that in the contrib part. If the
contrib calls an API that expects sbyte, wrap it in a code that does the
conversion (one extension method that we can later remove sounds perfect).

This way we don't need to do the same work twice.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Author of RavenDB in Action <http://manning.com/synhershko/>


On Tue, Apr 22, 2014 at 5:50 PM, Paul Irwin <pirwin@feature23.com> wrote:

> Please do not commit sbyte/byte changes with compile errors that affect
> Core or any of the contrib modules that were compiling previously
> (Analyzers, Query Parsers, etc). We have those libraries working at the
> moment, CLS compliance aside, and it will set us back to break the build of
> those projects preventing others from working.
>
> Also keep in mind that the sbyte usage rule only applies to public
> properties and method signatures. Private use of sbyte if needed is fine as
> far as CLS compliance is concerned.
>
>
> On Tue, Apr 22, 2014 at 8:30 AM, Ramkumar Krishnamoorthy <
> ramkumar1985@gmail.com> wrote:
>
> > Sure Itamar. I will remove all sbyte and replace it with byte.
> >
> > Do you want me to remove them in just contrib/spatial or through out the
> > solution? Because if I change them just in spatial, there will be compile
> > errors. Or I have to write some util extension methods to convert them
> just
> > inside the spatial, for the moment. Or do you want me to commit them with
> > compile errors?
> >
> > Cheers,
> > Ramkumar.K
> >
> >
> > On Tue, Apr 22, 2014 at 11:08 AM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > Hi again,
> > >
> > > 1. Please remove the use of sbyte. We pretty much agreed on the list to
> > > only expose byte externally, and unless there's a good reason to use
> > sbyte
> > > internally let's try and avoid that and the conversions that are needed
> > > later.
> > >
> > > 2. Please send a Pull Request to apache/lucene.net once done
> > >
> > > Thanks,
> > >
> > > --
> > >
> > > Itamar Syn-Hershko
> > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > Freelance Developer & Consultant
> > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > >
> > >
> > > On Mon, Apr 21, 2014 at 8:18 PM, Itamar Syn-Hershko <
> itamar@code972.com
> > > >wrote:
> > >
> > > > I'll have a look during the next week, thanks for your effort
> > > >
> > > > --
> > > >
> > > > Itamar Syn-Hershko
> > > > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > > > Freelance Developer & Consultant
> > > > Author of RavenDB in Action <http://manning.com/synhershko/>
> > > >
> > > >
> > > > On Mon, Apr 21, 2014 at 2:03 PM, Ramkumar Krishnamoorthy <
> > > > ramkumar1985@gmail.com> wrote:
> > > >
> > > >> Hi Guys,
> > > >>
> > > >> I think I have completed porting Contrib/Spatial and Spatial.NTS.
> > > >> Did run into couple of questions, but took some educated decisions.
> > > >>
> > > >> First is the usage of sbyte. I know there were some recent
> discussion
> > > >> about
> > > >> the usage of sbyte. And I did run into code, which needed sbyte as
a
> > > >> param.
> > > >> Since there is sbyte used already in the source and just to get it
> > > >> compiled
> > > >> for now, I have used sbyte. I guess there will be some task in
> future,
> > > if
> > > >> needed, to convert all sybte usage back to byte.
> > > >>
> > > >> The TermsEnumCompatibility and CompatibilityExtensions classes. I
> > > couldn't
> > > >> find the matching code in Java. And the code was not used anywhere
> > else,
> > > >> so
> > > >> not sure if we still needed these classes. Again just to get the
> code
> > > >> compiled, I have removed TermsEnumCompatibility class and deleted
> the
> > > >> error
> > > >> methods in CompatibilityExtensions.
> > > >>
> > > >> Hope I made the right decisions.
> > > >>
> > > >> Guess next step would be someone to review my changes. They can be
> > found
> > > >> at.
> > > >> https://github.com/cyberram/lucene.net/tree/branch_4x
> > > >>
> > > >> Cheers,
> > > >> Kumar
> > > >>
> > > >
> > > >
> > >
> >
>
>
>
> --
>
> Paul Irwin
> Lead Software Engineer
> feature[23]
>
> Email: pirwin@feature23.com
> Cell: 863-698-9294
>

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