Another thought occurred to me after sending this email. The contentious nature of these collections can be split into two sub-camps:
1. "Now I have to deal with class name conflicts in my application (java.util.HashMap and org.apache.pivot.collections.HashMap). Grrr." 2. "Why did you reinvent something that already existed?" To me, renaming the *package* might satisfy #2 but not #1. For instance, if, for the sake of argument, we called the package org.apache.pivot.model, then maybe the nature of why we didn't use the JDK classes will be more immediately apparent. After all, people didn't scream at Sun for creating javax.swing.ListModel. I'm not saying that "model" is the best term (it was off the cuff), but the point is that we might be able to satisfy one camp of complains with a package rename. As for complaint #1, that's tougher and more the subject of the opening email in this thread. -T On Wed, Aug 26, 2009 at 3:15 PM, Todd Volkert <[email protected]> wrote: > There's been talk of renaming our collection classes, because while they > serve technical value, they might cause confusion and frustration when used > in conjunction with the JDK collections in a large Java application. This > thread will serve as the place to brainstorm on what we could call them. > Note that many of the classes in the collections package aren't really under > scrutiny here, so let's start tightly focused on the really big and tough > ones: > > ArrayList > HashMap > LinkedList > > If changing the package name is not enough, then we have to come up with > different names for these classes. And yet their names hark back to the > early days of computer science - way before the JDK. One suggestion is to > prepend "P" or "Pivot" on to them, but at least to me, that seems like a > cop-out. Thus far, we've done a pretty good job avoiding words like > "Generic", "Default", "Abstract" as prepends to class names, as they tend to > not provide much value. The same goes for adding the package name in the > class name (com.foo.FooMap). Also, if we did this, then consistency would > seem to say that we should do the same for all classes in the package > (PivotEnumSet - yuck!). So where does that leave us? It seems that in > their current form, the fact that we created our own collections will be a > constant source of friction to our users and newbies, but (a) they do > provide real technical value, and (b) they're not easy to rename cleanly. > > Thoughts? > -T >
