Here's a use case:
I have objects that register themselves as listeners for system
notifications. When an object registers, I want to make sure we don't
add that object twice. If the listener list is an array, then I have
to iterate through the array every time we add a listener, which is
expensi
On Sep 11, 4:39 pm, kangax wrote:
> On Sep 11, 7:08 am, "T.J. Crowder" wrote:
> [...]
>
> > @Jim:
>
> > > Yep, this is Java-esque but that doesn't *always* equal evil!
>
> > Hardly ever! I'd say hashCode has a place.
>
> > Let's step back and ask the question: What are the use cases for a
> >
On Sun, 13 Sep 2009 01:39:43 +0400, kangax wrote:
>
> On Sep 12, 3:05 am, "artemy tregubenko" wrote:
>> This may used to unobtrusively store in a hash some data associated
>> with dom nodes.
>
> So DOM node would be a key? That doesn't really sound like a good
> idea. The whole purpose of ele
On Sep 12, 3:05 am, "artemy tregubenko" wrote:
> This may used to unobtrusively store in a hash some data associated with
> dom nodes.
So DOM node would be a key? That doesn't really sound like a good
idea. The whole purpose of element storage is to avoid having
references to DOM elements (for
Arty,
I believe that use case is used by element storage now. Instead of a
hash of DOM element to data, you can simply use an array of DOM
elements and they will have their storage attached. The speed would
probably be faster than a true hash.
Allen Madsen
http://www.allenmadsen.com
On Sat, S
This may used to unobtrusively store in a hash some data associated with
dom nodes.
On Fri, 11 Sep 2009 19:39:04 +0400, kangax wrote:
>
>
>
> On Sep 11, 7:08 am, "T.J. Crowder" wrote:
> [...]
>> @Jim:
>>
>> > Yep, this is Java-esque but that doesn't *always* equal evil!
>>
>> Hardly ever! I
May I ask you ?
Can I use Hash or vanilla objects for storing [key,value] with
key==='constructor' or key==='prototype' ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this grou
I'm with kangax on this one. I have never needed this functionality.
Allen Madsen
http://www.allenmadsen.com
On Fri, Sep 11, 2009 at 11:59 AM, James Aimonetti
wrote:
>
> My interest was piqued when reading
> http://www.timdown.co.uk/jshashtable/index.html if that helps further
> discussion of
My interest was piqued when reading
http://www.timdown.co.uk/jshashtable/index.html if that helps further
discussion of including the feature.
kangax wrote:
>
> On Sep 11, 7:08 am, "T.J. Crowder" wrote:
> [...]
>
>> @Jim:
>>
>>
>>> Yep, this is Java-esque but that doesn't *always* equa
On Sep 11, 7:08 am, "T.J. Crowder" wrote:
[...]
> @Jim:
>
> > Yep, this is Java-esque but that doesn't *always* equal evil!
>
> Hardly ever! I'd say hashCode has a place.
>
> Let's step back and ask the question: What are the use cases for a
> hash keyed by non-string objects? Are they compe
@Samuel:
> I've been working on this too and had quite reasonable performance
I like it, _should_ perform a *lot* better than a straight array given
a reasonable distribution of keys. This is similar to what Java's
HashMap does (not that I'm holding it up as a model of high
performance).
@Jim:
On Friday 11 September 2009 10:39:14 Samuel Lebeau wrote:
> Hi,
>
> I think it's indeed a good feature to discuss for 2.0.
> I've been working on this too and had quite reasonable performance
> when using a hash function that avoids collision.
> The simplest implementation consists in storing arra
Hi James,
You're right, Hash does indeed rely on underlying JavaScript vanilla
objects, which can only use strings as keys.
Supporting using objects as keys would be a complete rewrite, and a
fairly inefficient one in terms of runtime performance (I did it once,
and abandoned it as not worthwhil
13 matches
Mail list logo
