Revision: 8336
Author: rchan...@google.com
Date: Wed Jun 30 08:49:35 2010
Log: Cleaned a stray 'This' at the end of a sentence
http://code.google.com/p/google-web-toolkit/source/detail?r=8336
Modified:
/wiki/LightweightCollections.wiki
=======================================
--- /wiki/LightweightCollections.wiki Tue Jun 29 14:03:47 2010
+++ /wiki/LightweightCollections.wiki Wed Jun 30 08:49:35 2010
@@ -7,7 +7,7 @@
== Background and Motivation ==
_The JRE collections framework encode assumptions about the relationship
between types, objects, and their implementation making them highly
coupled, even at the top of the hierarchy._ For example, the `Map`
interface has methods such as `values()`, `entrySet()`, `keySet()` that
make very specific guarantees about how the returned objects interact with
the map from which they derive. These sorts of prescribed dependencies
between collection types (e.g. using a `Map` implies the use of `Set` and
`Collection`) and the behavior of collection objects themselves prevent
simple implementations. Repeated attempts to optimize GWT's emulated JRE
collections show a relatively high code-size cost for even minimal usage of
JRE collections because, for example, using a `Map` implies using a `Set`
and a `Collection`.
-_Too few collection types forces runtime enforcement of behaviors that
could be more efficiently modeled statically._ A common example is a class
`T` that wishes to return a reference an internal list. However, the `List`
interface has mutators (e.g. `add()`) which `T` would not want to make
possible "from the outside." The traditional best practice of calling
`Collections.unmodifiableList()` on the returned list reference requires
the allocation of an extra object (which generates extra GC runs that can
turn pathological in IE) as well extra code that must be generated simply
to implement `throw new UnsupportedOperationException()` when a mutator is
called on the wrapper object. If instead there were an `ImmutableList` type
that the list collections implement, class `T` could simply have returned
an immutable reference, which would ensure attempts to modify the list are
caught at compile-time (i.e. because `ImmutableList` has no mutators) and
which would prevent extra object allocations and potentially even
facilitate inlining at compile time. This
+_Too few collection types forces runtime enforcement of behaviors that
could be more efficiently modeled statically._ A common example is a class
`T` that wishes to return a reference an internal list. However, the `List`
interface has mutators (e.g. `add()`) which `T` would not want to make
possible "from the outside." The traditional best practice of calling
`Collections.unmodifiableList()` on the returned list reference requires
the allocation of an extra object (which generates extra GC runs that can
turn pathological in IE) as well extra code that must be generated simply
to implement `throw new UnsupportedOperationException()` when a mutator is
called on the wrapper object. If instead there were an `ImmutableList` type
that the list collections implement, class `T` could simply have returned
an immutable reference, which would ensure attempts to modify the list are
caught at compile-time (i.e. because `ImmutableList` has no mutators) and
which would prevent extra object allocations and potentially even
facilitate inlining at compile time.
_Under-specified semantics in JRE collections lead to defensive
programming in application code._ Java developers are encouraged to use the
least specific type that has the desired semantics. For example, such
advice would say use `List` in your code rather than `ArrayList`. However,
there is no guarantee that `List#get(int i)` returns in constant time, so a
generic algorithm written in terms of `List` cannot even be assured of its
expected time complexity. The JRE collections includes the tag interface
`RandomAccess` as a way to workaround the ambiguity, but forcing a check
such as `myList instanceof RandomAccess` is time consuming at runtime
(where time is precious) and, worse, can defeat the GWT compiler's
optimizer.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
