Re: HashMap (was "JIRA issues")

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

Noel,

These questions are challenges for sure, but they are hardly  
insurmountable:

> (1) What is the optimal fill factor for a HashMap?
> (2) Can you depend on client's to implement hashCode() properly?

Aren't these really application-level concerns? The fill factor is a  
property of the map. hashCode() must be implemented correctly  
regardless of whether the caller uses JDK collections or Pivot-native  
ones.

> (3) How do you implement fail-fast iterators to find concurrency  
> issues early?

Again, not an insurmountable problem. We had to do the same thing in  
ArrayList and LinkedList (and I think the solution in LinkedList works  
quite well).

> I count ___21___ bug fixes to the HashMap implementation in Apache
> Harmony. And this is __after__ it had been thoroughly tested and
> debugged before it was contributed.

Are you suggesting that, because another project had bugs in their  
implementation, the entire premise of implementing your own collection  
classes is flawed? I'm sure we'll have bugs - all software does. The  
potential for bugs doesn't mean it isn't worth doing. We're making  
fixes to the Pivot code base on a daily basis.

You make it sound as though building an entire UI toolkit from scratch  
is a cakewalk compared to implementing a basic collection class. Let  
me assure you, it isn't. Linked lists and hash tables are well-known,  
well documented data structures. They certainly require a minimum of  
CS knowledge to implement correctly, but they are not the proverbial  
"rocket science". I think we are all quite capable of rising to the  
challenge of implementing HashMap, LinkedList, or otherwise.

Please don't interpret this as a personal attack in any way. I'm just  
trying to respond to your concerns. But I have to admit that I am  
having a hard time understanding why you are so dead-set against this.

G

Re: HashMap (was "JIRA issues")

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

> Every time you add code to a project, you're adding to it's long- 
> term costs.

I agree with this. However, in this case, I feel that the effort is  
worthwhile.

> And the machinery for these collection classes is subtle and hard to
> get just-right.

Again, I don't think it is any more difficult than getting, say, focus  
management correct, and arguably far less so. As I said, these are  
well-documented data structures. Anyone with a CS textbook already has  
a manual for implementing them.

> Apache-Harmony have really good people working on this, and it took
> them quite a while to get right.
> Are you suggesting that we're that much smarter over here?

Not at all. Taking advantage of Harmony's code is certainly an option.  
However, I tried that approach with ArrayList and it wasn't a good  
fit, so I'm not convinced that it will work for HashMap.

Re: HashMap (was "JIRA issues")

[Noel Grandin <no...@gmail.com>]

Hi

I guess I'm dead-set because I really don't see why you're so strongly pro.
I could understand if you just thought this was a nice idea.
But you seem absolutely convinced that this is an unmitigated good thing.
And I just don't see it.

Every time you add code to a project, you're adding to it's long-term costs.
And the machinery for these collection classes is subtle and hard to
get just-right.
That's a junk of extra maintenance burden for a non-existent performance gain.

Apache-Harmony have really good people working on this, and it took
them quite a while to get right.
Are you suggesting that we're that much smarter over here?

Guys, I'll bow out of this discussion for now because I don't wish to
be divisive.

But if you're really going to do this, at the very least you should
consider copying HashMap from Harmony.
At least that way, you'll have the benefit of starting with thoroughly
debugged code.

Regards, Noel.



On Tue, Aug 11, 2009 at 02:03, Greg Brown<gk...@mac.com> wrote:
> Noel,
>
> These questions are challenges for sure, but they are hardly insurmountable:
>
>> (1) What is the optimal fill factor for a HashMap?
>> (2) Can you depend on client's to implement hashCode() properly?
>
> Aren't these really application-level concerns? The fill factor is a
> property of the map. hashCode() must be implemented correctly regardless of
> whether the caller uses JDK collections or Pivot-native ones.
>
>> (3) How do you implement fail-fast iterators to find concurrency issues
>> early?
>
> Again, not an insurmountable problem. We had to do the same thing in
> ArrayList and LinkedList (and I think the solution in LinkedList works quite
> well).
>
>> I count ___21___ bug fixes to the HashMap implementation in Apache
>> Harmony. And this is __after__ it had been thoroughly tested and
>> debugged before it was contributed.
>
> Are you suggesting that, because another project had bugs in their
> implementation, the entire premise of implementing your own collection
> classes is flawed? I'm sure we'll have bugs - all software does. The
> potential for bugs doesn't mean it isn't worth doing. We're making fixes to
> the Pivot code base on a daily basis.
>
> You make it sound as though building an entire UI toolkit from scratch is a
> cakewalk compared to implementing a basic collection class. Let me assure
> you, it isn't. Linked lists and hash tables are well-known, well documented
> data structures. They certainly require a minimum of CS knowledge to
> implement correctly, but they are not the proverbial "rocket science". I
> think we are all quite capable of rising to the challenge of implementing
> HashMap, LinkedList, or otherwise.
>
> Please don't interpret this as a personal attack in any way. I'm just trying
> to respond to your concerns. But I have to admit that I am having a hard
> time understanding why you are so dead-set against this.
>
> G
>
>