On 15/06/10 16:17, Andrea Aime wrote: > I still see an incompetent developer in action there. > You look at that interface, you get a Map, so you know: > - the API designer decided the iteration order was not important > - the iteration order cannot be trusted
Many other Map implementations have well-defined and lovingly crafted iteration orders. If we re-sort every Map we get we are losing information and duplicating effort. HashMap is the odd one out, for its notorious bad behaviour. > If you still rely on a specific iteration order well, you're the cause > of your own undoing... So: (1) Alice writes a module that uses a HashMap, and exposes it as a Map. Alice writes unit tests that make no iteration order assumptions. (2) Bob writes a module that uses Alice's module, takes the Map, and puts it in an ArrayList using its iteration order, and then exposes this list. Bob writes unit tests that do not make assumptions about the order of the items in the list. (3) Carol uses Bob's module, and writes unit tests that make assertions about the order of the list. These unit tests are likely nonportable. Alice could have protected her users either using LinkedHashMap or by not exposing her HashMap. This would have been defensive programming. -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
