Permalink
Show file tree
Hide file tree
3 comments
on commit
sign in to comment.
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Merge in data_nocollide branch. Fixes #6968, improves unit testing fr…
…amework checks for leaky stuff.
- Loading branch information
Showing
21 changed files
with
543 additions
and
229 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
e78d3a7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I am wrong but it looks like the changes effectively mean that for plain JS objects following is no longer true:
var obj = { name: "test" };
jQuery(obj).data("name") === obj.name; // is not true any more
But what about official jquery-datalink plugin?
And overall, regardless of the any plugin functionality, do you think it is justified to store any non-private data to obj[jQuery.expando] for plain JS objects instead of directly as properties of the object?
I completely agree that it is safer this way to store any internal information, like event bindings, within separate suboject. But why it is needed to break logical and justified behavior when the rest of the data keys are stored directly as object properties?
e78d3a7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@algor: You’re right! The behaviour here changes.
jQuery.data
is really for storing metadata on an object/element and so shouldn’t really meddle directly with properties. That was a change introduced between 1.4.2 and 1.4.3 in order to avoid memory leaks, and it is being restored to its original behaviour (w/o memory leaks) in 1.5. The datalink plugin is being rewritten from the ground-up and will not be using this functionality any more. :)e78d3a7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Colin, thank you very much for the clarifications!