Todd had a similar suggestion. While I understand the intent, I
personally don't think it is necessary. Why cater to developers who
would rather spout knee-jerk nonsense than actually attempt to
understand the value these classes offer?
I'm not 100% opposed to making a change such as this, but we really
need to put some thought into a) why we should do it and b) what
exactly we might change. Changing the package name probably isn't
sufficient, because there would still be overlap in the class names
themselves - and trying to come up with another name for "ArrayList",
for example, seems like going overboard to just for the sake of
appeasing lazy developers.
The bottom line is this - these classes *are* collection classes, and
should live in org.apache.pivot.collections, as they currently do. We
don't force developers to use them, and we have a number of solid
reasons for their existence, so I don't personally think we should
change anything.
G
On Aug 25, 2009, at 12:52 PM, Niclas Hedhman wrote:
Perhaps there is a simple solution, because I think Ralph has a
point that
these will be raised time and time again. I would like propose that
there
are name changes. Get rid of the contentious names, and no one will
care if
they are similar in function to collection classes...
-- Niclas
On Aug 26, 2009 12:13 AM, "Greg Brown" <[email protected]> wrote:
Here is another thing to consider. We have always considered Pivot
to be, to
some extent, what we think Sun should have done instead of JavaFX.
In other
words, if Sun was to create Swing right now, starting from scratch -
what
might it look like? We imagine that it might look a bit (or maybe a
lot)
like Pivot.
We applied the same mentality to our collections. If Sun was to
create the
JDK collections right now, and do so in conjunction with a new user
interface toolkit, what might they look like? Again, I think they
might end
up looking a lot like Pivot collections.
We have tried very hard in Pivot to only re-invent things that are
truly in
need of re-inventing. While the JDK collections may not fall into that
category on their own, when viewed from the perspective of someone
who wants
to use them as model classes, they do. They are simply not suitable
for that
purpose.
So, rather than saddle ourselves with the limitations of the existing
classes, we chose to start with a clean slate (as we did with our UI
classes). I personally think the result is far more positive than
negative.
On Aug 25, 2009, at 12:06 PM, Todd Volkert wrote: >> Please review
the FAQ
for the reasons behin...
