What this article taught me is that some javascript programmers do not understand pointers.<p>Considering how hard we have fought to liberate programmers from pointers, I am having mixed feelings about this lesson. One the one hand, what a paradise we live in that this person can imagine these sterile, useless contrivances are pointers. On the other hand, experience bij.
Psh, Cappuccino had this over a year ago: <a href="http://news.ycombinator.com/item?id=1233681" rel="nofollow">http://news.ycombinator.com/item?id=1233681</a>
The "free" function as written won't work.<p>When using Object.defineProperty if "configurable" is not set, the default is false (at least in Firefox, I don't recall what the spec says but I think it's just toBoolean whatever calling [[getownproperty]] "configurable" on the description object is, which would default to false), meaning the property cannot be deleted (or redefined).<p>(I'd also note not all browsers support defineProperty)<p>I'd also note to readers that the "delete" operator just removes a property name from an objects own property list, and has little to do with garbage collection directly. In this case I think the goal is to get rid of the closure created which handles the property, which I think would work (if the previous error is fixed), but I'm not familiar enough with JS engine internals to know.<p>I would probably just redefine the property to be "null". Once the property is null'd out, there's probably not much benefit to also removing the property from the property list.<p>With it null'd out as opposed to deleted you'd also not have to worry about an Object up the prototype chain punching through, and might be desirable in other ways.<p>Also note that this will not necessarily free up whatever was stored in the "pointer". I don't think that was the author's intention, but I just wanted to make that clear to readers.<p>If you did:
var foo = {};
foo = $(foo);
bar = $[foo];
$.free(foo);<p>The object created on the first line would not be garbage collected after free is called because bar now contains a reference to it.<p>If your goal was to clear up whatever was stored in "val" as well as the closure itself, you'd have to first set the property to null (to take care of "val"), and then redefine the property to null (to take care of the closure).<p>Of course, the biggest problem here is that this is pointless.<p>They are storing the value in a closure, but since they just expose the closure with get and set methods, they could just skip it all and us an Array.
Sometimes you really do just want to pass a value by reference. It turns out that most of the time you want to do this the variable already is an object or array already, nevertheless there are cases where this would be desirable, so it's not a bad idea when used carefully.<p>Having said that, malloc is a bad idea and completely unnecessary, and a nicer way to do the functionality might be to do:<p><pre><code> function pmk(val) { return { v: val }; }
function pget(p) { return p.v; }
function pset(p, val) { return p.v = val; }
</code></pre>
Doesn't need free'ing, at the minimal expense of creating one object per "pointer".<p>Neither of the solutions give you an "address of" type behaviour though :(
There are real references in JavaScript - when you pass objects. This case is completely ignored. I want to get the same pointer when it's the same object, even if the properties have changed. This is stubborn. I have solved this problem in a library - and you need to add the id to the object itself.
Anyway, explicit pointers are pretty "pointless" in JavaScript and should only used for recursion detection.
There's nothing wrong with this. It's a high level implementation of a memory system. The memory locations are represented as a JSON object:
{ 1: "some data", 2: "foo" ... }<p>It's not really needed in JavaScript but I remember implementing something similar in C for school.
The only problem I see with this approach is the Javascript-interpreter seeing through your pointer system and holding a reference to the object pointed to - which defeats the purpose of creating a possibility to segfault...
I wrote this post, and am alarmed by the publicity it's getting and the controversy it's causing. I NEVER meant this to be used to solve any problem, nor to be used in a real life situation at all. I didn't mean this as a joke or as satire. I wrote the as a PROOF OF CONCEPT, just to show some capabilities of javascript.
There are other solutions:
<a href="http://brandon.pulpexplosion.com/index.php/2010/05/javascript-pointers/" rel="nofollow">http://brandon.pulpexplosion.com/index.php/2010/05/javascrip...</a>