Here's why I described this as the "right" approach. The other day,
when we were discussing this, it occurred to me that one way to
address Ralph's and Noel's concerns might be to simply eliminate the
Pivot-native collection classes (ArrayList, LinkedList, etc.) and move
the adapter classes (ListAdapter, MapAdapter, and SetAdapter) up to
org.apache.pivot.collections proper. The adapter classes are clearly
named, so this wouldn't seem like an "artificial" or "contrived"
design, and they allow developers to both take advantage of Pivot's
collection interfaces and continue using the existing, well-known JDK
collection classes.
However, as Todd and I have reiterated, we think there are valid
reasons for continuing to support Pivot's native collection
implementations. It seemed to us that, if we leave the collections as
they are, but simply draw more attention to the adapter classes, we
might be able to address everyone's concerns. If you think that naming
collisions, performance, or anything else related to the use of Pivot-
native collections might be an issue, you are free to use the
adapters. Otherwise, you can continue to use the Pivot-native versions.
This way, we don't need to sacrifice one in favor of the other - both
options are available, and can be applied as appropriate based on an
individual developer's needs and tastes.
G
On Aug 29, 2009, at 2:51 AM, Niclas Hedhman wrote:
On Fri, Aug 28, 2009 at 8:01 PM, Greg Brown<[email protected]> wrote:
I think this is the right approach.
Time will tell if this is the right approach, and my take is that next
time either one of you get frustrated over someone asking "Why?"
again, I call it "not smart" and a failure to understand how other
people perceive your work... ;-)
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
