
Javascript Pointers - hanszeir
http://forrst.com/posts/Javascript_Pointers-9q3
======
KirinDave
What this article taught me is that some javascript programmers do not
understand pointers.

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.

~~~
oinksoft
What I would give for that comments section to be pubic...

------
jerf
This is either bad satire, or a bad idea.

~~~
technomancy
Are we ruling out good satire? Because, I mean... wow.

~~~
jerf
I've done my time helping people out on various fora, mostly comp.lang.python,
and seen this sort of thing in reality. If it's satire, the tipoff is too
small. I've seen "stupider" (or "beginninger" or some other term, if it makes
you fell better, I haven't got a good one).

------
deweller
Next up: malloc

Ok - now I'm convinced it is a joke. Dry humor, indeed.

~~~
city41
I don't think it's a joke. We don't have much context to go on. I get the
feeling the author was just exploring/experimenting. Implementing "pointers"
and some sort of malloc in javascript probably has very little practical
application, but the author may learn a bit more about how memory works. Maybe
that is his real goal.

------
paulbaumgart
Psh, Cappuccino had this over a year ago:
<http://news.ycombinator.com/item?id=1233681>

~~~
adrusi
yes, that's where I got the idea from, I just wanted to make the usage a bit
nicer

------
M1573RMU74710N
The "free" function as written won't work.

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.

~~~
adrusi
Yes I suppose `configurable` should be enabled. The reason I used delete
instead of setting to null is that null is considered just as important a
value as any other and if you had an outrageous number of nulls, it could
consume a noticeable amount of memory.

`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.

------
anc2020
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.

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;  }
    

Doesn't need free'ing, at the minimal expense of creating one object per
"pointer".

Neither of the solutions give you an "address of" type behaviour though :(

------
Andi
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.

------
sktrdie
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" ... }

It's not really needed in JavaScript but I remember implementing something
similar in C for school.

~~~
M1573RMU74710N
Hey, sorry to be pedantic but this is one of my pet peeves.

"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.

~~~
anc2020
I appreciate your enthusiasm for correctness, but if I'm reading correctly,
the essence of sktrdie's comment was trying to counter the group think that
the idea of the article is in some way "bad", "satirical", or "wrong".

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.

~~~
M1573RMU74710N
> he essence of sktrdie's comment

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".

~~~
anc2020
Okay, great, you're absolutely right that an Array would have been a better
choice of data structure, albeit marginally better.

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.

~~~
M1573RMU74710N
> marginally better.

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"
    

This code accomplishes the same thing but is much faster, leaner, simpler, and
cross-browser.

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.

------
flitzwald
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...

~~~
boucher
You can still have a null pointer exception.

~~~
flitzwald
That's not half as exciting as to write into the raw, uncharted territory of
your virtual address space...

------
adrusi
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.

------
kungfooguru
It has to be a joke. Its just a closure.

------
gildas
There are other solutions:
[http://brandon.pulpexplosion.com/index.php/2010/05/javascrip...](http://brandon.pulpexplosion.com/index.php/2010/05/javascript-
pointers/)

~~~
KirinDave
What problem does this solve? What problem do either of these ideas solve? Is
the question, "What is the best way to troll programmers on the internet?"

~~~
gildas
I wish it was the case...

