> On Oct 30, 2015, at 3:38 PM, David M. Lloyd <david.ll...@redhat.com> wrote: > > On 10/30/2015 03:39 PM, Mandy Chung wrote: >>> On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.ll...@redhat.com> wrote: >>> 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. >> >> Locals and operands is one experimental feature in mind that is not target >> for JDK 9. But it would be an interesting feature for e.g. Fibers to >> experiment. This will also allow JDK-specific capability to be implemented >> in the future. > > Ah, that makes sense, I forgot about cases where the JDK itself might have > non-spec extensions. It should probably be specified in the docs that > unrecognized options are either ignored or rejected though.
I decide to take out WalkerOption interface, as I didn’t like that as much for supporting one single known extension at the moment. I found another way doing it (by a factory method to return a StackWalker instance with extended capability). > >>> 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? >> >> Altering the first batch size would be useful for Log4J and Groovy use cases >> that filter implementation classes and finds the caller. Altering >> subsequent batch size is more as a flexible option. One can simple have the >> function to return the same batch size. > > Maybe an overload of walk() which accepts an int (initial batch size) in > addition to the function for the simple case? > Maybe. It’d be good to get further feedback and use cases to decide adding another variant. >> I do think IntSupplier is probably a better choice that won’t restrict to >> supply only the initial batch size. The last batch size parameter is >> solely for information. > > UnaryOperator is a good option too Yup. I have updated the API to use that. > (that's what I was looking for before), or maybe even ToIntFunction<X> where > X is something that might inform the next batch size based on the work that > has already been done - maybe even a Stream<StackFrame> that consists only of > the current batch? > > Or another idea: > <T> T walk(BiFunction<Stream<StackWalker.StackFrame>, IntConsumer, T> > function); > > where the IntConsumer can be called at any time to update a minimum number of > remaining frames needed, which in turn can (with the knowledge of how many > elements have been consumed by the stream) inform the next batch size. The stack walker won’t get the next batch until all frames of the current batch are consumed. I think the current walk methods would cover what this one does. There are other ideas to add other variants of the walk methods and short-cut for performance. I keep these ideas in mind and consider them once more feedback is collected. thanks Mandy
