concept of List.indexWhere functionality

[fallenreaper]

As a consumer of the dartlang, it seems that more often than not I am given an object with some primary key attributes, such as an ID and want to get that Index to deal with CSS or set flags. Right now, the use cases I have seen is either:

    int targetId = 5
    var item = list.firstWhere((obj)=>obj.id == targetId, orElse: ()=>null;
    var index = item==null? -1 : list.indexOf(item);

or:

    int index = 0;
    bool found = false;
    for (var item in list) {
      if (item.id == targetId) {
        found = true;
        break;
       }
       index++;
    }
    return found ? index : -1;

I have corrected my developers for using an ineffecient case (top) but thought it would be useful to implement a function for lists called: indexWhere

    int indexWhere(func, {orElse: ()=> -1){
      int index = 0;
      bool found = false;
      for (var item in list){
        if (func(item)){
          found = true;
          break;
        }
        index ++;
      }
      return found ? index : fn();
    }

[lrhn]

This would make sense as a method on List.
I don't think it's as useful on Iterable in general since the index is less important there (you can use elementAt, but you shouldn't do that a lot if it's not actually a list).

[fallenreaper]

Yea, I was thinking list would benefit the most since as you said it benefits more. I was thinking about implementing this and pushing it into Dart language. Figure it could be something worthwhile to have.

…

On Jul 30, 2017 18:57, "Lasse R.H. Nielsen" ***@***.***> wrote: This would make sense as a method on List. I don't think it's as useful on Iterable in general since the index is less important there (you can use elementAt, but you shouldn't do that a lot if it's not actually a list). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30275 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATP58J6gy3Xmr504dpxxlNSf6edkQVWks5sTQphgaJpZM4OkVIh> .

[lrhn]

See also #3711

[floitschG]

It should only be on List.
We should probably also make the signature match the one from indexOf: int indexWhere(func, [int start = 0]).

It should be relatively easy to go from -1 to the value the user wants.

[srawlins]

This landed, correct @lrhn? https://api.dartlang.org/dev/2.0.0-dev.47.0/dart-core/List/indexWhere.html

[lrhn]

It did, yes. Thanks.

[dotdoom]

If this ever gets any reconsideration, my 2cents: it could be useful on Iterator, too. I believe it's not different implementation-wise between List and Iterable, but BuiltList extends Iterable and not List.

Now with extension methods, if I want to add indexById() extension method on both List and BuiltList, I have to add it to Iterable and can't use indexWhere.

[fallenreaper]

I hope it is considered. Tempted to just implement and do a pull request.

…

On Sat, Dec 14, 2019, 10:15 Artem Sheremet ***@***.***> wrote: If this ever gets any reconsideration, my 2cents: it could be useful on Iterator, too. I believe it's not different implementation-wise between List and Iterable, but BuiltList extends Iterable and not List. Now with extension methods, if I want to add indexById() extension method on both List and BuiltList, I have to add it to Iterable and can't use indexWhere. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30275?email_source=notifications&email_token=AACM7Z6YIMZKWRMUCI7OQ2DQYT2B7A5CNFSM4DURKIQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4EYLI#issuecomment-565726253>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACM7Z7FKNY6AO7NVBCTIE3QYT2B7ANCNFSM4DURKIQQ> .

[lrhn]

It is very unlikely that a change to the Iterable class would be able to land at this time. It would break all existing implementations of Iterable that are not also a List.

(I also do not recommend indexing into Iterables by integers, it's very rarely going to be efficient).

[fallenreaper]

Correct. I was just thinking. Set for example is an iterable. Set has no indexing. So I think it would bes be exclusive to List/Arrays

…

On Sun, Dec 15, 2019, 07:01 Lasse R.H. Nielsen ***@***.***> wrote: It is very unlikely that a change to the Iterable class would be able to land at this time. It would break all existing implementations of Iterable that are not also a List. (I also do not recommend indexing into Iterables by integers, it's very rarely going to be efficient). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30275?email_source=notifications&email_token=AACM7Z6OPE46X5BPZCDPCKDQYYMCPA5CNFSM4DURKIQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4XSFA#issuecomment-565803284>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACM7ZZVUDE3QOOSQABN4KLQYYMCPANCNFSM4DURKIQQ> .

[fallenreaper]

@dotdoom i was looking at the DartLang docs, and this was implemented as a part of the the List class. It does not make sense for iterable as not all iterables are indexed like Lists are. There are likely other classes which would make use of indexWhere function, but to me, adding them as a mixin are also not the right way. I think that if there are other classes which may benefit from this, submit requests and someone will get to them.

[dotdoom]

@fallenreaper I don't see how it will hurt either (elementAt already paves the way for indexing Iterables), but it will clearly be beneficial for solving the problem I mentioned above.

[dotdoom]

@lrhn sure there are other methods that may be slow on certain implementations of iterable -- such as length, last etc. Iterables are full of catches, such as a single-shot iterable has to be converted to a list to take a second pass. That doesn't mean however that we should remove all those methods and keep only moveNext. The methods are there for convenience, and convenience is always a tradeoff.

Don't want to make a big deal out of it; I wanted to say that adding it to Iterable would solve one problem without introducing any other, that's all.

[fallenreaper]

@dotdoom I was looking at the recent implementation Iterable. You are actually correct, good call. I dont think that was a part of iterable when I was doing dart back then. I was looking at the underlying implementation of elementAt for example, and it starts at the beginning of the Iterable and walks in until index is determined, so unlike real implementation of Lists where access is O(1), access on an iterable is O(index). So it isnt all that good to me.

That being said, indexWhere, while it may make use because elementAt and firstWhere are implemented, after getting the index, accessing it through elementAt would still take time to access.

indexWhere, Runtime => O(N) to find the index.
elementAt, Runtime => O(N) to find the object BECAUSE elementAt is not O(1) access.
So, doing these will create issues of O(2*N) which isnt all that good in comparison to other options.

[dotdoom]

@fallenreaper indeed; however, consider that (and now I'm feel like I'm derailing the conversation too much)

• indexWhere() does not necessarily imply subsequent elementAt(); there are use cases where it's good to know the index (e.g. to count number of elements before a specific one)
• the calculations you have suggested are valid only for implementations that require sequential access, such as linked list; other implementations may win (vector, b-tree) or loose (computational, such as an iterable over digits of Pi) in performance.

P.S. O(2*N) = O(N) ;-)