Also, take a look at this: https://github.com/apache/lucene.net/pull/12
-- 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:55 PM, Itamar Syn-Hershko <[email protected]>wrote: > 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 <[email protected]> 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 < >> [email protected]> 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 < >> [email protected] >> > >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 < >> [email protected] >> > > >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 < >> > > > [email protected]> 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: [email protected] >> Cell: 863-698-9294 >> > >
