[infinispan-dev] ISPN-78 and Large Object Support/Streaming API

galder at jboss.org galder at jboss.org
Wed May 26 03:30:02 EDT 2010


----- "Manik Surtani" <manik at jboss.org> wrote:

> On 25 May 2010, at 07:30, Galder Zamarreno wrote:
> 
> > 
> > ----- "Manik Surtani" <manik at jboss.org> wrote:
> > 
> >> On 20 May 2010, at 16:14, Galder Zamarreno wrote:
> >> 
> >>> The following ties in a bit with my comment yesterday about
> return
> >> values:
> >>> 
> >>> If these two methods would always return null, you'd never be
> able
> >> to find out whether a remove/replace worked on its own. Returning
> >> previous value would indeed not work, but you could still return a
> >> marker different to null.
> >> 
> >> The problem with markers is typing.  Returning a boolean, for
> example,
> >> would make a lot of sense.  But returning anything else would in
> >> effect be used *as a boolean*.  Using any other return type for
> this
> >> would be abuse of the type system.
> > 
> > +1, a boolean would be enough.
> 
> Right, but that in turn breaks the method signature of remove() and
> replace(), which return V.  Hence my opting to return null and
> documenting as such.

Oh bugger, had forgotten of that and V is completely out of our control. Hmmm, that's a bummer.

> 
> > 
> >> 
> >> 
> >>> 
> >>> V remove(K key); // except that this will always return a null
> >>> V replace(K key, V value); // except that this will always return
> a
> >> null
> >>> 
> >>> So, if remove worked cos the key was present, a marker value
> would
> >> be returned, otherwise if the key was not present, null would be
> >> returned.
> >>> 
> >>> Cheers,
> >>> 
> >>> ----- "Manik Surtani" <manik at jboss.org> wrote:
> >>> 
> >>>> I have put together a brief design for ISPN-78.  Please take a
> >> look,
> >>>> it is on the wiki:
> >>>> 
> >>>> 	https://community.jboss.org/wiki/LargeObjectSupport
> >>>> 
> >>>> I have also deferred ISPN-78 to 5.0.0 rather than 4.1.0 as I'd
> >> rather
> >>>> not hold up 4.1.0 for new features at this stage.  
> >>>> 
> >>>> Please have a look at the designs and let me know what you think
> -
> >> or
> >>>> comment on the wiki page.
> >>>> 
> >>>> Cheers
> >>>> Manik
> >>>> --
> >>>> Manik Surtani
> >>>> manik at jboss.org
> >>>> Lead, Infinispan
> >>>> Lead, JBoss Cache
> >>>> http://www.infinispan.org
> >>>> http://www.jbosscache.org
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> infinispan-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> 
> >> --
> >> Manik Surtani
> >> manik at jboss.org
> >> Lead, Infinispan
> >> Lead, JBoss Cache
> >> http://www.infinispan.org
> >> http://www.jbosscache.org
> >> 
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


More information about the infinispan-dev mailing list