Revision: 7684
Author: rj...@google.com
Date: Fri Mar 5 10:33:58 2010
Log: Edited wiki page through web user interface.
http://code.google.com/p/google-web-toolkit/source/detail?r=7684
Modified:
/wiki/LightweightCollections.wiki
=======================================
--- /wiki/LightweightCollections.wiki Fri Mar 5 10:32:42 2010
+++ /wiki/LightweightCollections.wiki Fri Mar 5 10:33:58 2010
@@ -42,7 +42,7 @@
_Hosted mode collections implementations can differ, if necessary, from
web mode._ This follows from the previous point but is also practical —
because the development mode browser plug-in (was OOPHM) is based on IPC,
it may simply be harmfully slow to implement hosted mode collections using
JSNI.
-_Publish and guarantee time complexity for various operations._
+_Publish and guarantee time complexity for various operations._ That is,
publish via documentation and enforce empirically by monitoring automated
benchmarking tests.
_Keep implementations locked down._ Because it's very tricky to get the
implementations for these sorts of collections just right, the plan is to
minimize ways in which there could be confusion about the implementation of
a given collection type. More concretely, the key types should be classes
rather than interfaces so that their implementation can be restricted to
the package in which they are defined. If developers cannot trust that a
given collection instance is truly optimal and maintains time complexity
guarantees -- as might be the case if collections types were interfaces
which could have been implemented "anywhere" -- then they may feel
compelled to write defensive code. By locking the implementations down,
developers can rely on the behavior of a given collection type.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
