+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
+1 for renaming both.
2009/10/2 Samuel Lebeau
> 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
>
> I'd prefer isEmpty as well.
>> Allen Madsen
>> http://www.a
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
> I'd prefer isEmpty as well.
> Allen Madsen
> http://www.allenmadsen.com
>
>
>
> On Fri, Oct 2, 2009 at 3:34 PM, joneff wrot
I'd prefer isEmpty as well.
Allen Madsen
http://www.allenmadsen.com
On Fri, Oct 2, 2009 at 3:34 PM, joneff 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
Agreed +1
Allen Madsen
http://www.allenmadsen.com
On Fri, Oct 2, 2009 at 2:42 PM, Simon Charette wrote:
> 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 t
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 semanti
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
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 elem
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 cau
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
10 matches
Mail list logo
