StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2800524
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
4
CommunityOwnedDate
CreationDate
2010-05-10T05:36:05.047
FavoriteCount
0
LastActivityDate
2016-11-23T15:17:58.780
LastEditDate
2016-11-23T15:17:58.780
LastEditorUserId
157247
OwnerUserId
157247
ParentId
2800463
PostTypeId
2
Score
46
ViewCount
0
LastEditorDisplayName
text
Body
It's actually a very interesting area of Javascript. Details in <a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm" rel="noreferrer">the spec</a>, but: Javascript's way of handling local variables is quite different from the way C does it. When you call a function, amongst other things a "variable environment" for that call is created, which has something called a "binding object". (Call it the "variable object" for short; saying "the binding object of the variable environment" is just a tad bit long-winded!) The variable object has properties for the arguments to the function, all local variables declared in the function, and all functions declared within the function (along with a couple of other things). Unqualified references (e.g., the <code>foo</code> in <code>foo</code>, not <code>obj.foo</code>) within the function are first checked against the variable object to see if they match properties on it; if they do, those properties are used. When a closure survives the function returning (which can happen for several reasons), the variable object for that function call is retained in memory by the reference from the closure. At first glance, that would suggest that the stack isn't used for local variables; in fact, modern JavaScript engines are quite smart, and may (if it's worthwhile) use the stack for locals that aren't actually used by the closure. (Naturally, the stack is still used for keeping track of return addresses and such.) Here's an example: <pre><code>function foo(a, b) { var c; c = a + b; function bar(d) { alert("d * c = " + (d * c)); } return bar; } var b = foo(1, 2); b(3); // alerts "d * c = 9" </code></pre> When we call <code>foo</code>, a variable object gets created with these properties: <ul> <li><code>a</code> and <code>b</code> — the arguments to the function</li> <li><code>c</code> — a local variable declared in the function</li> <li><code>bar</code> — a function declared within the function</li> <li>(...and a couple of other things)</li> </ul> When <code>foo</code> executes the statement <code>c = a + b;</code>, it's referencing the <code>c</code>, <code>a</code>, and <code>b</code> properties on the variable object for that call to <code>foo</code>. When <code>foo</code> returns a reference to the <code>bar</code> function declared inside it, <code>bar</code> survives the call to <code>foo</code> returning. Since <code>bar</code> has a (hidden) reference to the variable object for that specific call to <code>foo</code>, the variable object survives (whereas in the normal case, it would have no outstanding references and so would be available for garbage collection). Later, when we call <code>bar</code>, a new variable object for that call is created with (amongst other things) a property called <code>d</code> — the argument to <code>bar</code>. Unqualified references within <code>bar</code> are first checked against the variable object for that call; so for instance, <code>d</code> resolves to the <code>d</code> property on the variable object for the call to <code>bar</code>. But an unqualified reference that doesn't match a property on its variable object is then checked against the next variable object in the "scope chain" for <code>bar</code>, which is the variable object for the call to <code>foo</code>. And since that has a property <code>c</code>, that's the property used within <code>bar</code>. E.g., in rough terms: <pre>+----------------------------+ | `foo` call variable object | | -------------------------- | | a = 1 | | b = 2 | | c = 3 | | bar = (function) | +----------------------------+ ^ | chain | +----------------------------+ | `bar` call variable object | | -------------------------- | | d = 3 | +----------------------------+</pre> Implementations are free to use whatever mechanism they want under the covers to make the above seem to happen. It's impossible to get direct access to the variable object for a function call, and the spec makes clear that it's perfectly fine if the variable object is just a concept, rather than a literal part of the implementation. A simple implementation may well just literally do what the spec says; a more complicated one may use a stack when there are no closures involved (for the speed benefit), or may always use a stack but then "tear off" the variable object needed for a closure when popping the stack. The only way to know in any specific case is to look at their code. :-) More about closures, the scope chain, etc. here: <ul> <li><a href="http://blog.niftysnippets.org/2008/02/closures-are-not-complicated.html" rel="noreferrer">Closures are not complicated</a></li> <li><a href="http://blog.niftysnippets.org/2008/03/poor-misunderstood-var.html" rel="noreferrer">Poor misunderstood 'var'</a></li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POHow variables are allocated memory in Javascript?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. UST.J. Crowder
UserOwnerUserId
1. UST.J. Crowder
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.