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
I do not insist this have to be in the core.
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 email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at