Agreed. Maybe this logic seems more prevalent than it is as I have just spent a day looking at lots of methods that use it.
I think it might still be feasible to get it to slot in to what we have now. After all it boils down to a kind of single use iterator really. I'll think it over, prototype and report back it it seems worth looking at. If not I will deny ever making the suggestion :) On 18 September 2010 06:42, Greg Brown <[email protected]> wrote: > Yeah, the main risk here is trying too hard to generalize. Sometimes trying > to make things fit into a common model ends up making the code more complex > or difficult to follow. However, I'm all for generalizing when it applies. > > On Sep 17, 2010, at 7:32 PM, Chris Bartlett wrote: > > > On 18 September 2010 06:24, Chris Bartlett <[email protected]> > wrote: > > > >> > >> > >> On 18 September 2010 05:59, Greg Brown <[email protected]> wrote: > >> > >>>>>>> 3. (Improvement / New Feature) > >>>>>>>> XXX.keyTyped() methods which select the next item matching the > >>> keypress > >>>>>>>> should probably > >>>>>>>> - Move in the opposite direction when SHIFT is pressed > >>>>>> > >>>>>> Just as before, it is a continuation of the SHIFT key reversing > >>> direction > >>>>> > >>>>> That's what I figured, but is this a common convention? I have never > >>> heard > >>>>> of it before. > >>>>> > >>>>> > >>>> I couldn't tell you of a single place off the top of my head where > this > >>>> does occur, but it was something that seemed natural to my (clearly) > >>>> perverted way of thinking ;) > >>> > >>> I can actually see the utility in it - but if it is not a widely known > >>> convention, users may not even think to try it, so not worth the effort > of > >>> coding/testing. > >>> > >>> I'd rather see some effort go into the wrapping functionality, since > this > >>> is actually a common convention that we don't currently support. > >>> > >>> > >>> > >> > >> I was thinking that it might be worth trying to consolidate the way this > >> kind of thing is handled throughout Pivot as it happens in a number of > >> places and the resulting code is not especially pretty. > >> > >> Something along the lines of > >> > >> public static int helperMethod(Sequence<T> items, int startIndex, > Direction > >> direction, Filter<T> filter) > >> > >> You would pass it the list of items, a starting point & direction of > >> 'travel'. > >> It would take care of the while loops to iterate over potentially the > >> entire sequence, until it finds an object T which fulfills the required > >> selection criteria (such as enabled and 'toString() starts with a letter > >> A') > >> > >> Possibly also include another boolean parameter to control if it 'wraps' > or > >> ends when it hits the Sequence bounds. > >> > >> Chris > >> > > > > Just thought this over a bit more and handling Sequences directly > wouldn't > > really help much here. Better if the method could handle common > components > > that require this type of processing and call the appropriate methods. > > Stuff like ListView.isItemDisabled() etc. > >
