[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