We Keep Coding

When/If to use Delete in Javascript

I just found out that javascript has a delete statement. I've read a bit about it and am not much the wiser.
So I am hoping to get a functional definition of when I should use it, if at all. So I know I can delete properties of an object; as is made obvious by this fiddle:
var myData = {a:"hello",b:"world"};
alert(myData.b);
delete myData.b;
alert(myData.b);
Which shows "world" then undefined in successive alerts. However, you cannot use delete like this (as one might in C++):
function data() {
this.attribute1 = "aww";
this.attribute2 = "poo";
}
var myData = new data();
delete myData;
Here delete returns false indicating that you cannot delete myData. I used to work primarily in C++ and this was like the whole idea of delete. I can't think of any reason I would use delete to remove properties. Should I ever worry about using delete to mark memory to be freed? Like if I do something like this.
var myData = new data();
... //do stuff
myData = new data();
Addition
So I dug up the post that confused me. The most upvoted answer on this question states (as quoted from the Apple Javascript Coding Guidelines):
Use delete statements. Whenever you create an object using a new statement, pair it with a delete statement. This ensures that all of the memory associated with the object, including its property name, is available for garbage collection. The delete statement is discussed more in “Freeing Objects.”
So, if I understand some of the comments and answers I've been given, this statement is not accurate, because you cannot even call delete on an object created using a new statement.

According to mozilla's developer documents, delete does not work that way.
The delete operator deletes a property from an object, it does not delete the object itself.
So instead of using it as you have demonstrated, you would use it more like the following:
myGlobalObject = {};
var myObject = {};
myObject.propertyA = "blah";
// Do some stuff
delete myObject.propertyA; // This works because you're deleting a property off myObject
delete myGlobalObject; // This works because myGlobalObject is a property of the global object.
delete myObject; // This does NOT work - most likely because you declared it using the var keyword
This doesn't actually do garbage collection though. Also if myObject has a prototype up the chain that has propertyA it would still inherit that property through the prototype.
For more indepth information feel free to check out the developer documents:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete

delete on its own specifically states:
The delete operator removes a property from an object.
You might remove a property if you don't want it included in data sent to a server, or used by other code, e.g., something that automatically takes object data and turns it into a table.
In general you'd never use it for memory management, a possible exception being if you had a huge chunk of data in an object (like received from the back end) that you explicitly don't need.

How to create an entirely independent associative array clone or copy in javascript, ie with no references to original data values?

I have been trying clone the following in such a way as to avoid all references to the original data:
initially, a d3.js selection, using the clone_d3_selection() method but which, though correctly duplicating DOM elements, maintains references to selection data (the d parameter in function calls)..
the array at it's heart, extracted using d3's selection.data() function. Cloning seems to fail in part because the target structure appears to be a mix of object and array, but moreover because what are claimed to be clones generally maintain references to the original data, meaning changes to one are reflected in the other. A further (but minor) issue has been that (generally) null elements were being copied...
Note: JSON.parse(JSON.stringify(object)) is of no use in either case, as it applies to objects, whereas d3 uses / coerces / outputs arrays).
Applied to an array, in all respects EXCEPT that it too replicates references, an object clone/copy function of the type shown below works fine. Despite the preserved references, it has been provided (and accepted) as a resolution to many a javascript-tagged object-cloning question.
function transfer(obj) {
var result = [];
for (var property in obj) {
if (obj.hasOwnProperty(property)) {
result[property.toString()] = arr[property];
}
}
return result;
};
I, however, really need complete independence from the current/original. Seems no matter what I do, references are copied.
How do I know? At regular intervals, the current selection/array is a) cloned then b) -with no further direct changes- designated previous. Beyond this point, any changes made to the clone are instantly reflected in the original - and remain through it's redesigation into previous.. The whole point of the clone was to avoid this..
sole
modifications!
:
v
--------> current ------> clone
^ :
: v
: previous
: :
merge.....:
Is there a better way, or might the code above be modified so that it provides a new, completely independent array, but bearing the same data values? Might this even be done directly to the original selection in a d3-centric way?
Incidentally, the array being cloned is simple enough, having been created along these lines:
var arr = [];
arr["key1"] = "value1";
arr["key2"] = 2;
: : :
... followed by the accustomed d3 append() call chain.
Incidentally, every attempt at a simulation outside my rather large codebase has become mired in data formatting issues. Just astonishing what a minefield this is..
Glad of any suggestions.
Thanks
Thug

To deep copy an array as retrieved from a d3.js selection using selection.data():
http://www.overset.com/2007/07/11/javascript-recursive-object-copy-deep-object-copy-pass-by-value/
This link (were it more easily found) turns to be provided in other answers, making this question something of a duplicate.
The problem will be encountered more frequently as d3.js's limits are pushed, though, so rather than delete it, here it stays...

When should I prefer a clone over an reference in javascript?

at the moment I'm writing a small app and came to the point, where I thought it would be clever to clone an object, instead of using a reference.
The reason I'm doing this is, because I'm collecting objects in a list. Later I will only work with this list, because it's part of a model. The reference isn't something I need and I want to avoid having references to outside objects in the list, because I don't want someone to build a construct, where the model can be changed from an inconsiderate place in their code. (The integrity of the information in the model is very important.)
Additional I thought I will get a better performance out of it, when I don't use references.
So my overall question still is: When should I prefer a clone over an reference in javascript?
Thanks!

If stability is important, then clone it. If testing shows that this is a bottleneck, consider changing it to a reference. I'd be very surprised if it is a bottleneck though, unless you have a very complicated object which is passed back and forth very frequently (and if you're doing that it's probably an indication of a bad design).
Also remember that you can only do so much to save other developers from their own stupidity. If they really want to break your API, they could just replace your functions with their own by copying the source or modifying it at runtime. If you document that the object must not be changed, a good developer (yes, there are some) will follow that rule.
For what it's worth, I've used both approaches in my own projects. For small structs which don't get passed around much, I've made copies for stability, and for larger data (e.g. 3D vertex data which may be passed around every frame), I don't copy.

Why not just make the objects stored in the list immutable? Instead of storing simple JSON-like objects you would store closures.
Say you have an object with two properties A and B. It looks like that:
myObj = {
"A" : "someValue",
"B" : "someOtherValue"
}
But then, as you said, anyone could alter the state of this object by simply overriding it's properties A or B. Instead of passing such objects in a list to the client, you could pass read-only data created from your actual objects.
First define a function that takes an ordinary object and returns a set of accessors to it:
var readOnlyObj = function(builder) {
return {
getA : function() { return builder.A; },
getB : function() { return builder.B; }
}
}
Then instead of your object myObj give the user readOnlyObj(myObj) so that they can access the properties by methods getA and getB.
This way you avoid the costs of cloning and provide a clear set of valid actions that a user can perform on your objects.

Javascript Object Identities

Objects in JavaScript have unique identities. Every object you create via an expression such as a constructor or a literal is considered differently from every other object.
What is the reason behind this?
{}==={}//output:false
For what reason they are treated differently? What makes them different to each other?

{} creates a new object.
When you try and compare two, separate new objects (references), they will never be equal.
Laying it out:
var a = {}; // New object, new reference in memory, stored in `a`
var b = {}; // New object, new reference in memory, stored in `b`
a === b; // Compares (different) references in memory
If it helps, {} is a "shortcut" for new Object(), so more explicitly:
var a = new Object();
var b = new Object();
a === b; // Still false
Maybe the explicitness of new helps you understand the comparison compares different objects.
On the other side, references can be equal, if they point to the same object. For example:
var a = {};
var b = a;
a === b; // TRUE

They are different instances of objects, and can be modified independently. Even if they (currently) look alike, they are not the same. Comparing them by their (property) values can be useful sometimes, but in stateful programming languages the object equality is usually their identity.

The fact that they're different is important in this scenario:
a={};
b={};
a.some_prop = 3;
At this point you'll obviously know that b.some_prop will be undefined.
The == or === operators thus allow you to be sure that you're not changing some object's properties, that you don't want changed

This question is quite old, but I think the actual solution does not pop out clearly enough in the given answers, so far.
For what reason they are treated differently? What makes them
different to each other?
I understand your pain, many sources in the internet do not come straight to the fact:
Object (complex JS types => objects, arrays and functions) variables store only references (=address of the instances in memory) as their value. Object identity is recognized by reference identity.
You expected something like an ID or reference inside the object, which you could use to tell them apart (maybe that's actually done transparently, under the hood). But every time you instantiate an object, a new instance is created in memory and only the reference to it is stored in the variable.
So, when the description of the ===-operator says that it compares the values, it actually means it compares the references (not the properties and their values), which are only equal if they point to the exactly same object.
This article explains it in detail: https://codeburst.io/explaining-value-vs-reference-in-javascript-647a975e12a0
BR
Michael

Both of the objects are created as a separate entities in the memory. To be precise, both of the objects are created as a separate entities on the heap (JavaScript engines use heap and stack memory models for managing running scripts). So, both of the objects may look the same (structure, properties etc.) but under the hood they have two separate addresses in the memory.
Here is some intuition for you. Imagine a new neighborhood where all houses are look the same. You've decided to build another two identical buildings and after finishing the construction both of the buildings are look the same and they even "sit" contiguously but still they are not the same building. They have two separate addresses.

I think that the simplest answer is "they are stored in different locations in memory". Although it is not always clear in languages that hide pointers ( if you know C, C++ or assembly language, you know what pointers are, if not, it is useful study to learn a low level language ) by making everything a pointer, each "object" is actually a pointer to a location in memory where the object exists. In some cases, two variables will point to the same location in memory. In others, they will point to different locations in memory that happen to have similar or identical content. It's like having two different URLs, each of which points to an identical page. The web pages are equal to each other, but the URLs are not.

Storing components in an Entity System

Note: this introduction is about entity systems. But, even if you don't know what these are, or haven't implemented them yourself, it's pretty basic and if you have general Javascript experience you will probably qualify more than enough to answer.
I am reading articles about Entity Systems on the T=machine blog.
The author, Adam, suggests that an entity should just be an id, that can be used to obtain it's components (ie, the actual data that the entity is supposed to represent).
I chose the model where all entities should be stored in "one place", and my primary suspects for implementing this storage are the array-of-arrays approach many people use, which would imply dynamic entity id's that represent the index of a component belonging to an entity, while components are grouped by type in that "one place" (from now on I'll just call it "storage"), which I plan to implement as a Scene. The Scene would be an object that handles entity composition, storage, and can do some basic operations on entities (.addComponent(entityID, component) and such).
I am not concerned about the Scene object, I'm pretty sure that it's a good design, but what I am not sure is the implementation of the storage.
I have two options:
A) Go with the array-of-array approach, in which the storage looks like this:
//storage[i][j] - i denotes component type, while j denotes the entity, this returns a component instance
//j this is the entity id
[
[ComponentPosition, ComponentPosition, ComponentPosition],
[ComponentVelocity, undefined, ComponentVelocity],
[ComponentCamera, undefined, undefined]
]
//It's obvious that the entity `1` doesn't have the velocity and camera components, for example.
B) Implement the storage object as a dictionary (technically an object in Javascript)
{
"componentType":
{
"entityId": ComponentInstance
}
}
The dictionary approach would imply that entity id's are static, which seems like a very good thing for implementing game loops and other functionality outside the Entity System itself. Also, this means that systems could easily store an array of entity ids that they are interested in. The entityId variable would also be a string, as opposed to an integer index, obviously.
The reason why I am against array-of-arrays approach is that deleting entities would make other entity ids change when a single entity is deleted.
Actual implementation details may wary, but I would like to know which approach would be better performance wise?
Things that I am also interested in (please be as cross-platform as possible, but if needed be, use V8 as an example):
How big is the overhead when accessing properties, and how is that implemented under the hoof? Lets say that they are being access from inside the local scope.
What is undefined in memory, and how much does it take? I ask this, because in the array-of-arrays approach all of the inner arrays must be of the same length, and if an entity doesn't have a certain component, that field is set to undefined.

Don't worry about the Array. It is an Object in JavaScript i.e. no "real" arrays, it's just the indices are a numeric "names" for the properties of the object (dictionary, hash, map).
The idea is simple, an Array has a length property that allows for loops to know where to stop iterating. By simply removing an element off the Array (remember, it's an Object) the length property doesn't actually change. So...
// create an array object
var array = ['one','two', 'three'];
console.log(array.length); // 3
// these don't actually change the length
delete array['two']; // 'remove' the property with key 'two'
console.log(array.length); // 3
array['two'] = undefined; // put undefined as the value to the property with key 'two'
console.log(array.length); // 3
array.splice(1,1); // remove the second element, and reorder
console.log(array.length); // 2
console.log(array); // ['one','three']
You've got to realize that JavaScript doesn't "work" like you expect. Performance wise objects and arrays are same i.e. arrays are accessed like dictionaries;
Scope is not like other "c style" languages. There are only global and function scopes i.e. no block scope (never write for(var i) inside another for(var i));
undefined in memory takes exactly the same amount as null . The difference is that null is deliberate missing of value, while undefined is just accidental (non-deliberate) missing;
Don't check if a field exists by doing if(array['two']) because, a field can actually hold the falsy values of undefined, null, 0, "", false and evaluate as false. Always check with if('two' in array);
When looping with for(key in array) always use if(array.hasOwnProperty(key)) so you don't iterate over a prototype's property (the parent's in a manner of speaking). Also, objects created by a constructor function might loop with the 'constructor' key also.