Removes comment syntax where possible for the following platform libraries:
* async
* collection
* convert
* core
* internal
* io
* math
The HTML related libraries are not changed. The templates used to build them
must be changed as well.
R=floitsch@google.com
Review URL: https://codereview.chromium.org/2529393002 .
This should help least-upper-bound computations to not think of EfficientLength
as completely separate from Iterable even though they are always used together.
It doesn't solve all problems with the least-upper-bound computation,
but at least some of the more often occuring ones.
R=floitsch@google.com
Review URL: https://codereview.chromium.org/2467113003 .
Committed: b08fb1373f
This should help least-upper-bound computations to not think of EfficientLength
as completely separate from Iterable even though they are always used together.
It doesn't solve all problems with the least-upper-bound computation,
but at least some of the more often occuring ones.
R=floitsch@google.com
Review URL: https://codereview.chromium.org/2467113003 .
This makes some nice code improvements for dart2js. dart2js can't
inline the MappedIterable factory constructor and specialize by
optimization, so specializing by hand removes the test "is
EfficientLength" for code like "x.where(f).map(g)".
R=lrn@google.com
Review URL: https://codereview.chromium.org/2354093002 .
It's still not a good solution for detecting an Iterable with an efficient
length. It's not inherited by, e.g., a DelegatingIterable wrapper or similar
generic Iterable transformers.
Keep this as an internal optimization for quickly detecting the most common
efficient-length Iterable classes (List, Set, Queue, Map.keys/values), but
don't make it public.
A *real* solution would be adding a hasEfficientLength getter to Iterable, or
adding an efficientLength getter that may return null if it's not efficient.
This would something that a wrapper can attach to.
R=sgjesse@google.com
Review URL: https://codereview.chromium.org//1154263003
in checked mode.
It also checks at the end in all cases.
Iteration only goes from 0 to the original length of the list.
This ensures that iterating a list while adding to it (like by x.addAll(x))
is caught instead of growing until out-of-memory.
For well-behaved programs this makes no difference since length and original
length stay the same.
Also, it means that calling moveNext again later, after increasing the length,
will not make iteration continue. After returning false, iteration is always
done.
However, it means that reducing the length causes an out-of-range read before
reaching the end, and before a concurrent modification error can happen.
R=sra@google.com
Review URL: https://codereview.chromium.org//1024843002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45198 260f80e4-7a28-3924-810f-c04153c831b5
Keep IterableBase around, but just extend Iterable.
There is no good reason to have IterableBase different from Iterable. The only argument is to be consistent with ListBase, but that's also inconsistent with, e.g., Stream.
ListBase only exists because List uses the default List constructor, so it's not a good super-class. As a usability-tradeoff, the ListBase class exists as a super-class.
Iterable doesn't have the same problem, so applying that "trade-off" has no up-side.
(A better long-term solution would be to be able to designate another constructor as the default "super()" constructor to call, so List could be used as a superclass).
R=sgjesse@google.com
Review URL: https://codereview.chromium.org//1025573005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45096 260f80e4-7a28-3924-810f-c04153c831b5
Most code in IterableMixinWorkaround was unused. The remaining O(20)
methods have been moved to their only use on JSArray.
I looked into using ListMixin on JSArray. The code was clearly worse
- nearly 1% bloat on swarm and some less precise inference. I think
it is reasonable to have the JSArray methods special-cased for
performance reasons.
R=lrn@google.com
Review URL: https://codereview.chromium.org//931283006
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44006 260f80e4-7a28-3924-810f-c04153c831b5
A previous change made these omit elements to keep the toString length down.
That could break code that expects the original behavior.
This still avoids using IterableMixinWorkaround.
Add static toString methods on ListBase, SetBase, IterableBase so that users can
get the same behavior as our toString methods, and with the same cycle detection
safety.
Unify all collection toString methods in two methods:
- IterableBase.iterableToShortString
- IterableBase.iterableToFullString
R=floitsch@google.com
Review URL: https://codereview.chromium.org//297053002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@36616 260f80e4-7a28-3924-810f-c04153c831b5
