On Mon, Aug 3, 2009 at 2:24 PM, Daniel Rice (דניאל רייס)<r...@google.com> wrote: > That could still theoretically fail if removeEldestEntry did something > weird that mutated the entries. But that seems pretty unlikely to be the > case.
Which is basically the tension between application code (just make it work for me) and library code (make it work for everybody). The clone-and-mutate approach is reasonable, assuming that any user-defined subtype of LHM would elect to preserve the Cloneable semantics. Is it any worse to say that if we can't determine the exact order that we would just fall back to insertion order and preserve the order of the map elements as they are presented to the CFS code? We can include a caveat that if the user really cares about having a LHM in access-order, they can create a new one on the client or in the server implementation method. -- Bob Vawter Google Web Toolkit Team --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
