> On Oct 30, 2015, at 1:26 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > Hi Mandy, hi David, hi all, > the API look gorgeous :) >
Thank you. > There are some missing wildcards in walk, > <T> T walk(Function<? super Stream<StackWalker.StackFrame>, ? extends T> > function, IntUnaryOperator batchSizeMapper) > > In StackWalker.Option, > i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, maybe ? > That’s a good alternative. > In StackWalker.StackTrace, > i think that asStackTraceElement() should be called toStackTraceElement(), > like Path.toFile, it's a convenient method to convert a StackFrame instance > to the legacy class StackTraceElement. StackFrame has all the information StackTraceElement has. It doesn’t seem that this method is necessary. I’m tempted to remove this default method. Any thought? > The documentation of getDeclaringClass() is not clear that it throws UOE if > the walker is not configured with CLASS_REFERENCE. > I’ll fix that. > ----- Mail original ----- >> >> >> >> Clever/interesting way to prevent the stream from being used outside of >> the stack frame it is active in. I was trying to think of a way it >> could be subverted but I haven't come up with one yet. > > store the stream in an instance or a static variable ? > I have a test for all these cases. >> >> Since this is very likely to be a one-implementation API, is there a >> reason to have a separate WalkerOption interface and Option enum? Seems >> like you could just skip the interface. >> > > I agree with David, having another implementation is unlikely. That’s for an experimental capability (see my other reply). > >> The batchSizeMapper should probably be something better than a >> Function<Integer,Integer>, no? All that boxing seems unnecessary... the >> next best candidate I can see though is IntToLongFunction. I wonder why >> we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself >> should be somehow made aware of the optimum batch size. What's the use >> case for changing the batch size as you iterate? Is the traversal >> *that* expensive? > > IntToIntFunction => IntUnaryOperator. > Thanks. Mandy
