Yes, I was going to mention onXXX being common for event handler names (e.g onMouseClick), but didn't bother for the same reason you mentioned - it's irrelevant to this situation.
On Tuesday, February 23, 2016, Paul Benedict <pbened...@apache.org> wrote: > The onXXX prefix does have precedent as event handler callbacks, but this > method does not fit that purpose. Thus, I agree dropping "on" is sensible. > On Feb 23, 2016 8:48 PM, "Vitaly Davidovich" <vita...@gmail.com > <javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrote: > >> On Tuesday, February 23, 2016, Doug Lea <d...@cs.oswego.edu >> <javascript:_e(%7B%7D,'cvml','d...@cs.oswego.edu');>> wrote: >> >> > On 02/23/2016 04:30 PM, Vitaly Davidovich wrote: >> > >> >> Why not drop the (superfluous, IMO) "on" prefix while you're changing >> the >> >> receiver? >> >> >> > >> > Because then it reads as if the method itself is doing a spinWait. >> >> vs who else logically speaking? We all know there's a runtime underneath >> Java, there's no point in explicitly calling that out here. Again, how is >> this different from Thread::yield or any of the other mentioned examples? >> This is splitting hairs perhaps but there's no onXXX precedent to follow >> and this just throws an oddly looking method name into the mix. >> >> > "onSpinWait" is the only proposed name that no one has said they cannot >> > live with. So, live with it :-) >> >> Perhaps that's because the Runtime placement was a more glaring issue? :) >> It's livable but I just don't see the point of the prefix (and yes, I read >> the description of the intent in the original mail). >> >> > >> > -Doug >> > >> > >> > >> >> On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene <g...@azul.com >> <javascript:_e(%7B%7D,'cvml','g...@azul.com');>> wrote: >> >> >> >> >> >>> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com >> <javascript:_e(%7B%7D,'cvml','mark.reinh...@oracle.com');> wrote: >> >>>> >> >>>> 2016/1/28 9:25 -0800, g...@azul.com >> <javascript:_e(%7B%7D,'cvml','g...@azul.com');>: >> >>>> >> >>>>> This thread seems to have "hopped away" to the concurrency-interest >> >>>>> list in mid-Dec-2015. This posting is intended to capture a summary >> of >> >>>>> reasoning and some of the discussion there so that we have it in the >> >>>>> record in core-libs-dev. Mostly by including the contents of several >> >>>>> posts in the continuations of the original thread. >> >>>>> >> >>>>> See thread continuations here: >> >>>>> >> >>>>> >> >>> >> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14576 >> >>> >> >>>> and here: >> >>>>> >> >>>>> >> >>> >> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/thread.html#14580 >> >>> >> >>>> >> >>>>> Summary: >> >>>>> >> >>>>> ... >> >>>>> >> >>>> >> >>>> Thanks for the summary. >> >>>> >> >>>> I still don't buy the argument that this method belongs in >> j.l.Runtime. >> >>>> >> >>>> To say that this method should go there because it's an instruction >> to >> >>>> the run-time system is pretty weak. I agree with Vitaly [1] that if >> >>>> that's the threshold for adding methods to the Runtime class then >> lots >> >>>> of other stuff belongs there as well, including much of what's now in >> >>>> java.lang.Thread and java.util.concurrent and, arguably, anything >> else >> >>>> related to interacting with the environment in which the application >> >>>> runs (file and network I/O, process manipulation, etc.). >> >>>> >> >>>> This thread-related method really belongs in either java.lang.Thread >> or >> >>>> java.util.concurrent.LockSupport. j.l.Thread already has plenty of >> >>>> expert-level static methods related to the current thread, one of >> which >> >>>> (Thread::yield) is even a hint, just like this one. >> j.u.c.LockSupport >> >>>> is even more obviously intended for expert users and hence may be the >> >>>> best choice, but I could live with either one. >> >>>> >> >>> >> >>> Ok. In the interest of moving forward, lets settle on: >> >>> >> >>> Thread.onSpinWait() >> >>> >> >>> Same logic for the name, different receiver for the event. I can >> >>> certainly >> >>> live with it, and Doug seems ok with it as well. >> >>> >> >>> — Gil. >> >>> >> >>> >> >> >> > >> > >> >> -- >> Sent from my phone >> > -- Sent from my phone
