My vote (in case some of you are not aware of it) is to leave the
names as-is. As Todd says, Sun didn't invent these terms - they have
been around for a long time. Calling these classes anything other than
what they are seems artificial (and confusing).
Yes, it might be a pain to combine a Pivot ArrayList and a JDK
ArrayList in the same source file, but realistically, that's not
likely to happen very often. If you are writing a Pivot app, you are
most likely going to be using Pivot collections (at least, in your
Pivot code). You may have some server-side code that uses JDK
collections, but, in general, that shouldn't conflict with what you
are doing in the UI. On the other hand, if you are using Pivot's
QueryServlet class, you may find that you want to use Pivot's
collections on the server as well.
We have considered various alternatives in the past, and nothing
seemed to fit better than what we have right now. However, if you do
have a suggestion as to how we might cleanly resolve this, please let
us know.
Thanks,
Greg
On Aug 26, 2009, at 3:15 PM, Todd Volkert 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
