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 >
