Collections

[Ralph Goers <ra...@dslextreme.com>]

These discussions on HashMap have me concerned. I asked why this  
project was developing its own collection classes a while ago but the  
answer was less than satisfying. Seeing folks spending their time  
benchmarking internally developed HashMap implementations vs using the  
JDK really makes me wonder.

IIRC the answer I was given was that Pivot needs variations of the  
Collection classes - that they need to contain methods that aren't in  
the standard collection classes.

If that about sums it up then I think you need to revisit the problem.  
There are much better ways to add extensions to classes then  
reimplementing them. And having your own Map & List interfaces as well  
as implementations with the same names (albeit in different packages)  
as those in the JDK and that aren't based on the JDK interfaces is  
going to result in perpetual confusion by anyone picking up this  
project, especially since they are exposed to applications using the  
project.

Yes, I understand that java.util.Map isn't a collection. But the cure  
seems to be worse than the solution.

Ralph

Re: Collections

[Ralph Goers <ra...@dslextreme.com>]

On Aug 25, 2009, at 9:00 AM, Greg Brown wrote:

>>> Please review the FAQ for the reasons behind Pivot's collection  
>>> implementations.
>>>
>>> http://cwiki.apache.org/PIVOT/frequently-asked-questions-faq.html
>>
>> Yes, I've read them. None of them justify doing this to yourselves  
>> or your users.  There are much better ways to accomplish your goals.
>
> Oh? How much time have you invested in learning about Pivot's  
> architecture? We have been working on this platform for 2+ years,  
> and we think this represents the *best* way to accomplish our goals.  
> Until you can demonstrate the same depth of experience that has  
> brought us to this point, I don't think you are really qualified to  
> comment. Sorry.
>


Bye.

Re: Collections

[Greg Brown <gk...@mac.com>]

>> Please review the FAQ for the reasons behind Pivot's collection  
>> implementations.
>>
>> http://cwiki.apache.org/PIVOT/frequently-asked-questions-faq.html
>
> Yes, I've read them. None of them justify doing this to yourselves  
> or your users.  There are much better ways to accomplish your goals.

Oh? How much time have you invested in learning about Pivot's  
architecture? We have been working on this platform for 2+ years, and  
we think this represents the *best* way to accomplish our goals. Until  
you can demonstrate the same depth of experience that has brought us  
to this point, I don't think you are really qualified to comment. Sorry.

Re: Collections

[Greg Brown <gk...@mac.com>]

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" <gk...@mac.com> 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...

Re: Collections

[Niclas Hedhman <ni...@hedhman.org>]

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" <gk...@mac.com> 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...

Re: Collections

[Greg Brown <gk...@mac.com>]

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 behind Pivot's collection
>>> implementations.
>>>
>>> http://cwiki.apache.org/PIVOT/frequently-asked-questions-faq.html
>>>
>>
>> Yes, I've read them. None of them justify doing this to yourselves  
>> or your
>> users.  There are much better ways to accomplish your goals.
>
>
> I re-read the FAQ just now, and I think I have more to add that  
> might make
> you look at the pivot collections in a new light.
>
> A windowing toolkit such as ours is designed using the MVC paradigm,  
> and
> there's a need fora set of classes to act as the model.  In Swing's  
> case,
> they created BoundedRangeModel, ButtonModel, ComboBoxModel, ListModel,
> ListSelectionModel, MutableComboBoxModel, SingleSelectionModel,
> SpinnerModel, ToggleButtonModel, etc.  What we did was to create a  
> small set
> of unified classes that can not only serve as the model for all our
> components, but also act as generic interfaces for indexed or keyed  
> data.
> The ubiquitous use of these classes is part of what makes Pivot not  
> only
> efficient, but very easy to use once you grok the design.
>
> Now, once you've created these classes, do you put them in
> org.apache.pivot.wtk?  No.  They're also of use outside the windowing
> toolkit.  Call them collection classes, data classes, model classes,
> whatever, but there was a need for which they were created, they  
> satisfy
> that need very elegantly, and at the end of the day, they're of  
> general use
> just as lego blocks are, so they live in the core module.
>
> -T

Re: Collections

[Todd Volkert <tv...@gmail.com>]

> Please review the FAQ for the reasons behind Pivot's collection
>> implementations.
>>
>> http://cwiki.apache.org/PIVOT/frequently-asked-questions-faq.html
>>
>
> Yes, I've read them. None of them justify doing this to yourselves or your
> users.  There are much better ways to accomplish your goals.


I re-read the FAQ just now, and I think I have more to add that might make
you look at the pivot collections in a new light.

A windowing toolkit such as ours is designed using the MVC paradigm, and
there's a need fora set of classes to act as the model.  In Swing's case,
they created BoundedRangeModel, ButtonModel, ComboBoxModel, ListModel,
ListSelectionModel, MutableComboBoxModel, SingleSelectionModel,
SpinnerModel, ToggleButtonModel, etc.  What we did was to create a small set
of unified classes that can not only serve as the model for all our
components, but also act as generic interfaces for indexed or keyed data.
The ubiquitous use of these classes is part of what makes Pivot not only
efficient, but very easy to use once you grok the design.

Now, once you've created these classes, do you put them in
org.apache.pivot.wtk?  No.  They're also of use outside the windowing
toolkit.  Call them collection classes, data classes, model classes,
whatever, but there was a need for which they were created, they satisfy
that need very elegantly, and at the end of the day, they're of general use
just as lego blocks are, so they live in the core module.

-T

Re: Collections

[Ralph Goers <ra...@dslextreme.com>]

Ralph

On Aug 25, 2009, at 8:43 AM, Greg Brown wrote:

> This has been discussed at length.

And will continue to be every time someone new starts to participate  
in the project. If you really enjoy dealing with that then don't do  
anything about it.

> Please review the FAQ for the reasons behind Pivot's collection  
> implementations.
>
> http://cwiki.apache.org/PIVOT/frequently-asked-questions-faq.html

Yes, I've read them. None of them justify doing this to yourselves or  
your users.  There are much better ways to accomplish your goals.

Ralph

>
>
> On Aug 25, 2009, at 11:37 AM, Ralph Goers wrote:
>
>> These discussions on HashMap have me concerned. I asked why this  
>> project was developing its own collection classes a while ago but  
>> the answer was less than satisfying. Seeing folks spending their  
>> time benchmarking internally developed HashMap implementations vs  
>> using the JDK really makes me wonder.
>>
>> IIRC the answer I was given was that Pivot needs variations of the  
>> Collection classes - that they need to contain methods that aren't  
>> in the standard collection classes.
>>
>> If that about sums it up then I think you need to revisit the  
>> problem. There are much better ways to add extensions to classes  
>> then reimplementing them. And having your own Map & List interfaces  
>> as well as implementations with the same names (albeit in different  
>> packages) as those in the JDK and that aren't based on the JDK  
>> interfaces is going to result in perpetual confusion by anyone  
>> picking up this project, especially since they are exposed to  
>> applications using the project.
>>
>> Yes, I understand that java.util.Map isn't a collection. But the  
>> cure seems to be worse than the solution.
>>
>> Ralph
>

Re: Collections

[Greg Brown <gk...@mac.com>]

This has been discussed at length. Please review the FAQ for the  
reasons behind Pivot's collection implementations.

http://cwiki.apache.org/PIVOT/frequently-asked-questions-faq.html


On Aug 25, 2009, at 11:37 AM, Ralph Goers wrote:

> These discussions on HashMap have me concerned. I asked why this  
> project was developing its own collection classes a while ago but  
> the answer was less than satisfying. Seeing folks spending their  
> time benchmarking internally developed HashMap implementations vs  
> using the JDK really makes me wonder.
>
> IIRC the answer I was given was that Pivot needs variations of the  
> Collection classes - that they need to contain methods that aren't  
> in the standard collection classes.
>
> If that about sums it up then I think you need to revisit the  
> problem. There are much better ways to add extensions to classes  
> then reimplementing them. And having your own Map & List interfaces  
> as well as implementations with the same names (albeit in different  
> packages) as those in the JDK and that aren't based on the JDK  
> interfaces is going to result in perpetual confusion by anyone  
> picking up this project, especially since they are exposed to  
> applications using the project.
>
> Yes, I understand that java.util.Map isn't a collection. But the  
> cure seems to be worse than the solution.
>
> Ralph