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: Vote for CLS Compliance
Date Thu, 10 Apr 2014 22:37:15 GMT
I vote +1 for CLS compliance

Paul - if there has to be copying involved we should just support those
operations on byte[]. I agree it's going to be easier to keep up with Java
when using sbyte[], but I think there are only few places where we will
have such conflicts / differences, and there we can find creative ways of
solving this and documenting it properly (or use helper classes) so we this
keeps documented and in-sight in future cycles.

Let's tackle this head on asap?

--

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


On Thu, Apr 10, 2014 at 8:10 PM, Paul Irwin <pirwin@feature23.com> wrote:

> My vote is yes, since CLS compliance only applies to the public methods and
> properties. We should still strongly consider using sbyte internally to
> maintain logic compatibility with Java.
>
> IMHO: If there are public members that would require a Buffer.BlockCopy
> byte[]-to-sbyte[] conversion, we should consider warning the user that the
> performance may be impacted, and maintain an overload/alternative sbyte[]
> method that is usable by C# callers without the performance impact, by
> marking those methods as [CLSCompliant(false)] while retaining the
> [assembly:CLSCompliant(true)] at the assembly level. Said another way,
> let's allow for the sbyte[] public members with the [CLSCompliant(false)]
> attribute on the method, but make sure we have CLS-compliant alternatives.
>
>
>
>
> On Thu, Apr 10, 2014 at 12:55 PM, Zachary Gramana <zgramana@gmail.com
> >wrote:
>
> > +1 And across languages! : )
> >
> > On Apr 10, 2014, at 9:43 AM, Prescott Nasser <geobmx540@hotmail.com>
> > wrote:
> >
> > > I think this is important to achieve to really make this available
> cross
> > platform.
> > > ________________________________
> > > From: michael herndon<mailto:mherndon@michaelherndon.com>
> > > Sent: 4/10/2014 6:02 AM
> > > To: dev@lucenenet.apache.org<mailto:dev@lucenenet.apache.org>
> > > Subject: Vote for CLS Compliance
> > >
> > > Cross Language Specification Compliance Vote
> > >
> > > This vote is to make Lucene.Net CLS Compliant moving forward with
> version
> > > 4.
> > >
> > > The benefit of CLS Compliance is that other languages on the .NET
> Runtime
> > > can use Lucene.Net. There have been issues with in the past where
> people
> > > using VB.NET could not consume parts of the library because it was not
> > > Compliant.
> > >
> > > The con is that it will take time and effort to get this right.
> > >
> > > Feel free to discuss the pros and cons before voting.
> > >
> > > *voting rules*: https://www.apache.org/foundation/voting.html
> > > *compliance documentation*:
> > > http://msdn.microsoft.com/en-us/library/12a7a7h3(v=vs.110).aspx
> > >
> > > -M
> >
> >
>
>
> --
>
> 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