Agreed on your take of the two camps.
It is possible that #1 naturally resolves itself - as I said in my
previous email, how often are you really going to need to use both
Pivot and JDK collections in the same class file? Not often, I'd guess.
Renaming "collections" to "model" may seem to address #2, but does it
really, or is it just obfuscation? I think it is the latter. I also
think it tends to make the nature of these classes less clear. As a
developer, I would expect this package to be called "collections", not
"model".
G
On Aug 26, 2009, at 3:22 PM, Todd Volkert wrote:
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
