If the methods are providing a Supplier (to the Statistic) shouldn't they
be called 'set{Int,Long,Double}Supplier'?On Thu, Jun 2, 2016 at 11:04 AM, Dan Smith <[email protected]> wrote: > Replies inline. > > On Thu, Jun 2, 2016 at 10:04 AM, Darrel Schneider <[email protected]> > wrote: > > > It is not clear to me how the new apis behave. > > Is the supplier for a particular id/name/descriptor remembered by the > > Statistics instance? So if you wanted to add an intSupplier for a int > > statistic you would do it once by calling sampleInt? > > > > Yeah, that's what I was going for. You install the supplier once and then > it gets called every sample. > > > > > The name of these methods give the impression that calling it will take a > > sample. Perhaps it should be setSampler? Do you need the type (int, long, > > etc) in the name or is overloading ok? > > > > I'll rename it to setSampler, that seems clearer. Name overloading should > work, but I was trying to be consistent with the existing methods. We have > incInt, intLong, incDouble. Should I follow a different pattern for these > setSampler methods? > > > > Does the supplier need to match the type of the stat otherwise you get > > IllegalArgumentException? > > > > That seems like a good idea, I'll clarify that in the javadocs. > > > > Can you only have one sampler registered for a particular stat? If so > > should these methods return the old one? > > > > Seems like a good idea. I was also thinking maybe for completeness if you > set the sampler to null it will remove it. I'll clarify the javadocs. > > > > How does a sampler interact with the existing methods on the same stat? > Do > > the "get" methods implicitly call the sampler to compute the result they > > return? If so then the "set" and "inc" methods become noops. > > > > I was thinking get would just return the last sampled value - it would > not > trigger an immediate recomputation. But it's true that set and inc are > basically useless if you have a supplier set. > > -Dan >
