Looks like you are right and the iterator does not account for such a behavior in case of remove(). If remove() can really result in a different key ordering then iteration can fail to work properly. Adding an element to the underlying collection while iterating is not an issue as the Iterator JavaDoc/Contract already defines that iteration behavior is undefined if the underlying collection is modified by other means than Iterator.remove().
The supported property names on a Storage object are the keys of each key/value pair currently present in the list associated with the object, in the order that the keys were last added to the storage area.
I am wondering if this can be useful for an alternative iterator implementation as this sentence defines an ordering which should not change when removing items.
-- I think GWT has been lucky here so far and browsers do not re-order existing storage entries if you remove a key/value pair. Also the key(n) doc says:
I am wondering if this can be useful for an alternative iterator implementation as this sentence defines an ordering which should not change when removing items.
-- J.
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment