Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As others have said: This "extra variable" is (at some level) the only way to get about the fact that <code>this</code> is a special expression and thus, being not a variable, is not bound in an execution context/closure.</p> <p>However, what I think you are asking (or what I really want to answer) is:</p> <blockquote> <blockquote> <p>Should one put <code>var self = this</code> at the top of every method/constructor?</p> </blockquote> </blockquote> <h3>Summary</h3> <p>While I tried this once, and had the same question, I no longer use this approach. Now I reserve the construct for when I need access in a closure. To me it adds a little "hey, this is what I really want!" semantic to my code:</p> <p><code>this -&gt; this</code> and <code>self -&gt; this (but really that) in a closure</code></p> <h3>Questions ala carte:</h3> <blockquote> <blockquote> <p>...Although this is commonly done, it feels a bit wrong. What I'm hoping to find in this question is a better way to deal with this, or a something to convince me this is quite alright.</p> </blockquote> </blockquote> <p>Do what feels right to you. Don't be afraid to try one method and switch back later (but please try to remain consistent within each project :-)</p> <blockquote> <blockquote> <p>Is this the standard way to keep the correct bindings around? Should I standardize on using 'self' everywhere, unless i explicitly need 'this'.</p> </blockquote> </blockquote> <p>"self" is the most common name used. As per above, I prefer the opposite approach -- to use <code>this</code> except when a closure binding is required.</p> <blockquote> <blockquote> <p>..if it's considered a bit evil and why.</p> </blockquote> </blockquote> <p>Evil is a silly subjective term (albeit fun sometimes). I've never said it was evil, just why I do not follow the approach. Some people tell me I am "evil" for not using semi-colons. I tell them they should actually come up with good arguments and/or learn JavaScript better :-)</p> <blockquote> <blockquote> <p>I'm aware there's also the 'apply' built-in javascript function to explicitly define scope when calling a method. Is it better?</p> </blockquote> </blockquote> <p>The problem with <code>apply/call</code> is that you must use them at point of the function invocation. It won't help if someone <em>else</em> calls one of your methods as the <code>this</code> may already be off. It's most useful for doing things like the jQuery-style callbacks where the <code>this</code> is the element/item of the callback, etc.</p> <h3>As an aside...</h3> <p>I <em>like to avoid "needing self" on members</em> and thus generally promote all member functions to properties where the receiver (<code>this</code>) just "flows through", which is normally "as expected".</p> <p>The "private" methods in my code begin with a "_" and if the user calls them, that's on them. This also works better (is required, really) when using the prototype approach to object creation. However, <a href="http://www.crockford.com/javascript/private.html" rel="noreferrer">Douglas Crockford disagrees</a> with this "private" approach of mine and there are some cases where the look-up chain may thwart you by injecting an unexpected receiver:</p> <p><strong><em>Using the "self" bound in the constructor also locks the upper limit of the look-up chain for a method</em></strong> (it is no longer polymorphic upward!) which may or may not be correct. I think it's normally incorrect.</p> <p>Happy coding.</p>
    singulars
    1. This table or related slice is empty.
    1. POIs var self = this; a bad pattern?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs var self = this; a bad pattern?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COGreat answer. Could you elaborate on this statement: "I like to avoid "needing self" on members and thus generally promote all member functions to properties where the receiver (this) just "flows through", which is normally "as expected"." How do you do this?
      singulars
      1. PO
      1. USEvert
    2. CO@Evert If every method is a member of the object, it will/should be invoked as some form of `obj.member` which will normally ensure the `this` is correct (since `obj->this(obj)->this(obj)->...`). If you see the Crockford link in the post, you will see that the private method approach breaks the pattern as the private "methods" are now stored in variables in the constructor and thus not invoked in the `obj.member` form. This will throw off `this` inside them (as `this` is merely the receiver of the function at time of invocation -- `obj` in the above examples) unless extra work is done.
      singulars
      1. PO
      1. This table or related slice is empty.
    3. CO`aelf` is the window object -- I would avoid using reserved words, and use `var that = this` or `var _self = this`
      singulars
      1. PO
      1. USchovy
 

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.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload