Two things occur to me:
1) Doing 'instance = instance.clone(); instance.clear()' will guarantee that
neither the current map nor any of its entries can be affected.  The only
way something bad could happen would be if clone() or clear() were
overridden to do something weird, but that would surely be a violation of
the contract of LinkedHashMap.  We can't be expected to correctly RPC
classes that violate their own superclass constraints.

2) To use RPC with a subclass of LinkedHashMap, the user will need to
provide an additional _CustomFieldSerializer implementation anyway.  Correct
me if I'm wrong about that -- I just created a subclass with no additional
fields and RPC fails due to mismatched expectations between server and
client.  If they do so, they can ensure that the access order is exported in
a way that their subclass can deal with.

  In general, do we document how to deal with the interaction
between custom field serialization and subclassing?

Dan

On Mon, Aug 3, 2009 at 2:43 PM, BobV <[email protected]> wrote:

>
> On Mon, Aug 3, 2009 at 2:24 PM, Daniel Rice (דניאל רייס)<[email protected]>
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to