On Sun, 13 Sep 2009 01:39:43 +0400, kangax <kan...@gmail.com> wrote:

>
> On Sep 12, 3:05 am, "artemy tregubenko" <m...@arty.name> 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 the reasons of leaky circular
> references in IE and general quirkiness of host object extensions).
> Element storage already allows to associate arbitrary data with any
> (well almost any) element by giving that element a unique id, then
> using that id as a key in a hash (with data being a corresponding
> value). This approach works pretty well most of the time (it only
> doesn't work on elements that disallow extensions) and I don't see
> what benefit hashes with non-string keys would bring there.
>
> Could you please explain?

Yes, I meant using dom element as a key. The solution someone proposed  
before (array of arrays) doesn't use host object extensions and I think it  
doesn't increase risk of circular references too. I wanted to put in a  
hash i.e. data about whether some element was handled in some way and to  
use the hash like that:

     if (!handled.get(element)) handle(element);

Here `handled` is a hash, and `#get` can return either `undefined` for  
missing key or `false` for existing key with false value.

Anyway, when thinking about that idea, I totally forgot about element  
storage. Same task will be completed using following code

     if (!element.getStorage().handled) handle(element);

This quite simple too, however it has small downside. Using this approach  
you have only one storage per element and you might have key collisions  
for different code blocks, so you have to namespace keys, which will make  
code less readable. I acknowledge this is a rare condition for dom nodes.

However if I need to store same data for common objects (not dom nodes) I  
still have collisions issue while not having risks of circular references  
etc. In that case it is still more convenient to use objects as keys for  
some hashes.

I do not insist this have to be in the core.

> --
> kangax
> >


-- 
arty ( http://arty.name )

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to