Javascript Pointers
forrst.com
forrst.com
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.
Yes... yes, there's room in the lexicon for this. Nice.
Ok - now I'm convinced it is a joke. Dry humor, indeed.
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).
(I'd also note not all browsers support defineProperty)
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.
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.
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.
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.
If you did: var foo = {}; foo = $(foo); bar = $[foo]; $.free(foo);
The object created on the first line would not be garbage collected after free is called because bar now contains a reference to it.
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).
Of course, the biggest problem here is that this is pointless.
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.
`free` only releases the data stored in the global pointer object, not the original variable itself, that's not possible.
I don't know how many time's I've had to say this, but this was never intended to actually be used, just as a proof of concept.
Having said that, malloc is a bad idea and completely unnecessary, and a nicer way to do the functionality might be to do:
function pmk(val) { return { v: val }; }
function pget(p) { return p.v; }
function pset(p, val) { return p.v = val; }
Neither of the solutions give you an "address of" type behaviour though :(
It's not really needed in JavaScript but I remember implementing something similar in C for school.
"JSON" is a way to serialize data to in a string. It's based on Javascript's object literal syntax.
JSON has absolutely nothing to do with this article.
What you mean is the memory locations are stored in an Object (or if you want to be specific about the language "a Javascript Object)
If you want to refer to Javascript's handy way of creating objects like so: var x = {};
That is an "object literal" (which also has little to do with the article)
I'd also note that there is something wrong with this as they could get the same behavior (only faster, smaller, and cross-browser) by just using an Array.
It may be that I only ever merit to use this pattern once every 10,000 lines, but that in no way makes the idea of calling with reference over primitive values incorrect. Readers should understand the difference between rare and never.
Sure, however the first part of my comment is not intended to address the essence of their comment, so it has no bearing. What they said is incorrect, and in fact a common mistake and I wanted to correct it.
However, I'd also note that what sktrdie is describing is an Array (in Javascript an Array is just an object with numbers for property names and some helper methods).
As far as I can see there is absolutely zero benefit (and many drawbacks) in using the technique outline in the OP article as opposed to just using an Array.
You could get the same result by simply using an Array directly...or if you want to get fancy, add a few simple helper methods.
In this way (and perhaps others) the article is "bad" and "wrong".
That was not my qualm, and neither does it seem to be the qualm of other commenters on this page. Of course, I'm having to second-guess the reasons of other commenters because they were disinclined to note them, but am simply contesting the notion that the article is satirically bad.
I'm not so sure.
As written it's wasteful of resources and not cross-browser. (also not entirely functional)
All the stuff with the closure and defineProperty is basically pointless....
In the end what they have is an object with numbers for properties, and they are sticking values in those properties. That's an array.
All the hoops they jump through don't do anything except heat up the processor and waste resources, with nothing in return for that.
Consider this code which does the same thing:
var $ = function(val) {
var addr = $.mem.length;
$.mem[ addr ] = val;
return addr;
}
$.mem = [];
var foo = "foo";
foo = $( foo );
console.log( foo ) // 0
console.log( $.mem[foo] ) // "foo"
I'd also say that all of this doesn't really do much to inform one about "pointers". Learning about the link between pointers and arrays in certain other languages might be helpful for some JS developers, but there's none of that here. Here is just a roundabout array implementation that doesn't really teach the reader anything.
I'm not going to spit on the efforts of someone who is trying to learn something, or be condescending about it (at least not intentionally)....but I think it's necessary to point this sort of thing out so everyone walks away the wiser.
The linked article, however, makes no sense. The author does not seem to understand how JavaScript works. Arrays are not copied when passed to another function.