Iterable

[Dzenan Ridjanovic]

In 

Iterable<E> abstract class

http://api.dartlang.org/docs/releases/latest/dart_core/Iterable.html

abstract E firstWhere(bool test(E value), {E orElse()})

Returns the first element that satisfies the given predicate f.

Should it be?

abstract E firstWhere(bool f(E element), {E orElse()})

test -> f

value -> element (as in other methods)

[Bob Nystrom]

Yes, that sounds right. Can you file a bug?

Thanks!

- bob

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
 
 

[Florian Loitsch]

thanks.

https://codereview.chromium.org/15697020/

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[Dzenan Ridjanovic]

You are fast!

I have 2 questions concerning 

E elementAt(int index)

in Iterable.

Its corresponding method is in List

 int indexOf(E element, [int start = 0]) 

(1) Should the elementAt method be moved to List?

(2) All other methods in Iterable do not have element in their names (e.g., single and not singleElement). Why not simply at for elementAt?

[Ladislav Thon]

> (1) Should the elementAt method be moved to List?
>
> (2) All other methods in Iterable do not have element in their names (e.g., single and not singleElement). Why not simply at for elementAt?

It should really be operator []. List already has that, and if Iterable is supposed to have it too, there's really very little sense in giving it an extra name.

LT

[Dzenan Ridjanovic]

I have a question concerning the length property in Iterable. It is final.

List implements Iterable and there is a set method for the length property. 

I do not understand why the final property can be set?

[Dzenan Ridjanovic]

Iterable does not have operators.

[Matthew Butler]

On Thursday, May 23, 2013 11:02:09 AM UTC-3, Dzenan Ridjanovic wrote:

I have a question concerning the length property in Iterable. It is final.

List implements Iterable and there is a set method for the length property. 

I do not understand why the final property can be set?

As I understand it (and please someone correct me if I'm wrong). Iterable doesn't actually have a 'final' property. Rather it has a 'length' getter, which for convenience sake can be shown/written as a final property. List's can be growable, or they can be fixedSize. For growable lists (default type of list), List implements the getter for length but also provides its own setter, which can be considered a non-final property.

So even though we may write it as 'final x' in a class, behind the scenes it actually translates to be something like 'var _x; <type> get x => _x;' Any class that implements the class doesn't need to implement a final property named 'x', it need only to implement a getter named x. It can then also choose to implement a setter if they so choose.

Matt

  

[Ladislav Thon]

> I have a question concerning the length property in Iterable. It is final.
>
> List implements Iterable and there is a set method for the length property. 
>
> I do not understand why the final property can be set?

If an interface prescribes a final variable, it in fact prescribes a getter. Implementation of that interface is free to add a setter on top.

LT

[Ladislav Thon]

> Iterable does not have operators.

There's no difference between methods and operators.

The real reason, I presume, is that not all Iterables can be indexed in O(1), but I'm not buying that.

LT

[Bob Nystrom]

On Thu, May 23, 2013 at 7:16 AM, Matthew Butler <butler....@gmail.com> wrote:

As I understand it (and please someone correct me if I'm wrong).

You are exactly right.

- bob

[Bob Nystrom]

On Thu, May 23, 2013 at 7:22 AM, Ladislav Thon <lad...@gmail.com> wrote:

The real reason, I presume, is that not all Iterables can be indexed in O(1), but I'm not buying that.

My guess is it's either:

1. Like you suggest they want [] to imply O(1) and Iterable can't ensure that.

2. They didn't think to move this up to Iterable when the other stuff was reorganized.

File and bug so we can find out?

- bob

[Dzenan Ridjanovic]

Does the following from the elementAt doc applies to the corresponding operator?

Note: if this does not have a deterministic iteration order then the function may simply return any element without any iteration if there are at least index elements in this.

[Ladislav Thon]

The real reason, I presume, is that not all Iterables can be indexed in O(1), but I'm not buying that.

My guess is it's either:

1. Like you suggest they want [] to imply O(1) and Iterable can't ensure that.

2. They didn't think to move this up to Iterable when the other stuff was reorganized.

File and bug so we can find out?

Mmkay, http://dartbug.com/10829

LT

[Florian Loitsch]

On Thu, May 23, 2013 at 6:49 PM, Dzenan Ridjanovic <dze...@gmail.com> wrote:

Does the following from the elementAt doc applies to the corresponding operator?

If you have an operator you would expect it to return something specific to the index.

This sentence is just saying an iterable is allowed to cheat when you can't tell. We should just remove the sentence.

Note: if this does not have a deterministic iteration order then the function may simply return any element without any iteration if there are at least index elements in this.

On Thursday, May 23, 2013 12:09:02 PM UTC-4, Bob Nystrom wrote:

On Thu, May 23, 2013 at 7:22 AM, Ladislav Thon <lad...@gmail.com> wrote:

The real reason, I presume, is that not all Iterables can be indexed in O(1), but I'm not buying that.

My guess is it's either:

1. Like you suggest they want [] to imply O(1) and Iterable can't ensure that.

2. They didn't think to move this up to Iterable when the other stuff was reorganized.

File and bug so we can find out?

- bob

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new