[Prototype-core] Re: Memory Leak in IE
On Thursday 01 October 2009 21:56:30 Mike Rumble wrote: You could also encapsulate this in a function wrapping Element#remove, which IMHO is something Prototype should do out of the box. Quite disagree: * If I remove an element and add it elsewhere, I don't expect its events to have been de-registered. The code that moves the element shouldn't have to be aware of the (possibly unrelated) code that added the event listeners in order to ask it to add them again. * Removing from the document is not the same as allowing to be GC'd * Some elements may never be added to the document. Eg, an XML document which you download, manipulate then build some HTML representation of. Perhaps you want to monitor for mutations and keep the HTML in sync? [1] Jim [1] Not actually possible in IE or Chrome/Safari but would be nice if it were. In Chrome DOM mutation events only fire if the element is in the document: http://jimhigson.blogspot.com/2009/09/chrome-and-dom-mutation-events.html -- Jim my wiki ajaxification thing: http://wikizzle.org my blog: http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Memory Leak in IE
Exact, an element removed may be add it elsewhere and my purpose is
out
It remains that the proposal of Mike
element.descendants (). invoke ( 'stopObserving');
element.stopObserving ();
But I find it rather heavy for the developer who must insert code to
delete each element and can also cause performance's problems.
Could not we consider making public the method _destroyCache and add
it an optional parameter ancestor?
Expl :
function destroyCache(ancestor) {
ancestor = $(ancestor);
for (var i = 0, length = CACHE.length; i length; i++) {
if (!ancestor)
|| (CACHE[i].descendantOf // Possible on Window / Document
Elements
(CACHE[i].descendantOf(ancestor)
|| CACHE[i].match(ancestor))) {
Event.stopObserving(CACHE[i]);
CACHE[i] = undefined;
}
}
CACHE = CACHE.reject(Object.isUndefined);
}
This method could be integrated also at the AjaxUpdater before
replacing the content ?
Franck,
On 2 oct, 10:06, Jim Higson j...@wikizzle.org wrote:
On Thursday 01 October 2009 21:56:30 Mike Rumble wrote:
You could also encapsulate this in a function wrapping Element#remove,
which IMHO is something Prototype should do out of the box.
Quite disagree:
* If I remove an element and add it elsewhere, I don't expect its events to
have been de-registered. The code that moves the element shouldn't have to be
aware of the (possibly unrelated) code that added the event listeners in order
to ask it to add them again.
* Removing from the document is not the same as allowing to be GC'd
* Some elements may never be added to the document. Eg, an XML document which
you download, manipulate then build some HTML representation of. Perhaps you
want to monitor for mutations and keep the HTML in sync? [1]
Jim
[1] Not actually possible in IE or Chrome/Safari but would be nice if it were.
In Chrome DOM mutation events only fire if the element is in the
document:http://jimhigson.blogspot.com/2009/09/chrome-and-dom-mutation-events
--
Jim
my wiki ajaxification thing:http://wikizzle.org
my blog:http://jimhigson.blogspot.com/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Prototype-core] Re: Memory Leak in IE
Ok, good points that I hadn't considered. However, I would think that many developers will just use Event#remove without considering the need to remove the event listeners, which could lead to memory leaks. Maybe an Element#destroy method could fill this gap - remove event listeners, remove element from the DOM and then trash it - a destructive method for when the developer says OK, I'm done with this element... On Oct 2, 9:06 am, Jim Higson j...@wikizzle.org wrote: On Thursday 01 October 2009 21:56:30 Mike Rumble wrote: You could also encapsulate this in a function wrapping Element#remove, which IMHO is something Prototype should do out of the box. Quite disagree: * If I remove an element and add it elsewhere, I don't expect its events to have been de-registered. The code that moves the element shouldn't have to be aware of the (possibly unrelated) code that added the event listeners in order to ask it to add them again. * Removing from the document is not the same as allowing to be GC'd * Some elements may never be added to the document. Eg, an XML document which you download, manipulate then build some HTML representation of. Perhaps you want to monitor for mutations and keep the HTML in sync? [1] Jim [1] Not actually possible in IE or Chrome/Safari but would be nice if it were. In Chrome DOM mutation events only fire if the element is in the document:http://jimhigson.blogspot.com/2009/09/chrome-and-dom-mutation-events -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Memory Leak in IE
Element#destroy would definitely be useful. +1 I really think this is a better idea then making a public interface to reach destroyCache since it resolves into one function call and the learning curve (making difference between remove and destroy) is smaller since you don't have to teach developer the whole EventCache concept and why they should call the related function. Simon 2009/10/2 Mike Rumble mike.rum...@gmail.com Ok, good points that I hadn't considered. However, I would think that many developers will just use Event#remove without considering the need to remove the event listeners, which could lead to memory leaks. Maybe an Element#destroy method could fill this gap - remove event listeners, remove element from the DOM and then trash it - a destructive method for when the developer says OK, I'm done with this element... On Oct 2, 9:06 am, Jim Higson j...@wikizzle.org wrote: On Thursday 01 October 2009 21:56:30 Mike Rumble wrote: You could also encapsulate this in a function wrapping Element#remove, which IMHO is something Prototype should do out of the box. Quite disagree: * If I remove an element and add it elsewhere, I don't expect its events to have been de-registered. The code that moves the element shouldn't have to be aware of the (possibly unrelated) code that added the event listeners in order to ask it to add them again. * Removing from the document is not the same as allowing to be GC'd * Some elements may never be added to the document. Eg, an XML document which you download, manipulate then build some HTML representation of. Perhaps you want to monitor for mutations and keep the HTML in sync? [1] Jim [1] Not actually possible in IE or Chrome/Safari but would be nice if it were. In Chrome DOM mutation events only fire if the element is in the document: http://jimhigson.blogspot.com/2009/09/chrome-and-dom-mutation-events -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Suggestion: String#isEmpty instead String#empty
I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
I'd prefer isEmpty as well. Allen Madsen http://www.allenmadsen.com On Fri, Oct 2, 2009 at 3:34 PM, joneff jon...@gmail.com wrote: I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
I totally agree. `Array#isEmpty` would be useful too. Maybe we should rename those methods and deprecate the original names in 1.7. Best, Samuel. 2009/10/2 Allen Madsen bla...@gmail.com I'd prefer isEmpty as well. Allen Madsen http://www.allenmadsen.com On Fri, Oct 2, 2009 at 3:34 PM, joneff jon...@gmail.com wrote: I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
+1 for renaming both. 2009/10/2 Samuel Lebeau samuel.leb...@gmail.com I totally agree. `Array#isEmpty` would be useful too. Maybe we should rename those methods and deprecate the original names in 1.7. Best, Samuel. 2009/10/2 Allen Madsen bla...@gmail.com I'd prefer isEmpty as well. Allen Madsen http://www.allenmadsen.com On Fri, Oct 2, 2009 at 3:34 PM, joneff jon...@gmail.com wrote: I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty
+1 for REMOVE this methods --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
