What is the difference between remove and destroy

I read the documentation on KineticJS Docs and it says that:

destroy() - remove and destroy self

remove() - remove self from parent, but don't destroy

If what I understand is correct, the remove() function removes the node from the parent but is still allocated in the memory. Whereas destroy() completely frees the memory, is that correct? Can somebody explain in layman terms what are some complications if I used destroy over remove?

Thank you in advance.

Warmest Regards, Dandy Ling

I believe you are right, but just to add to what you said I would think that you would use:

remove() - to remove a node and possibly use that node later

destroy() - to destroy a node completely if you know you won't need this node any longer

Also, here are some benefits and disadvantages to Garbage Collection taken directly from the wiki: http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29

Benefits

Garbage collection frees the programmer from manually dealing with memory deallocation. As a result, certain categories of bugs are eliminated or substantially reduced:

Dangling pointer bugs, which occur when a piece of memory is freed while there are still pointers to it, and one of those pointers is dereferenced. By then the memory may have been re-assigned to another use, with unpredictable results.

Double free bugs, which occur when the program tries to free a region of memory that has already been freed, and perhaps already been allocated again.

Certain kinds of memory leaks, in which a program fails to free memory occupied by objects that have become unreachable, which can lead to memory exhaustion. (Garbage collection typically does not deal with the unbounded accumulation of data that is reachable, but that will actually not be used by the program.)

Efficient implementations of persistent data structures Some of the bugs addressed by garbage collection can have security implications.

Disadvantages

Typically, garbage collection has certain disadvantages:

Garbage collection consumes computing resources in deciding which memory to free, even though the programmer may have already known this information. The penalty for the convenience of not annotating object lifetime manually in the source code is overhead, which can lead to decreased or uneven performance. Interaction with memory hierarchy effects can make this overhead intolerable in circumstances that are hard to predict or to detect in routine testing.

The moment when the garbage is actually collected can be unpredictable, resulting in stalls scattered throughout a session. Unpredictable stalls can be unacceptable in real-time environments, in transaction processing, or in interactive programs. Incremental, concurrent, and real-time garbage collectors address these problems, with varying trade-offs.

Non-deterministic GC is incompatible with RAII based management of non GCed resources. As a result, the need for explicit manual resource management (release/close) for non-GCed resources becomes transitive to composition. That is: in a non-deterministic GC system, if a resource or a resource like object requires manual resource management (release/close), and this object is used as 'part of' another object, then the composed object will also become a resource like object that itself requires manual resource management (release/close).