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> wrote:
> On Tuesday, February 23, 2016, Doug Lea <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> wrote: > >> > >> > >>> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote: > >>>> > >>>> 2016/1/28 9:25 -0800, 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 >
