First, the concept ofthisis a C# thing, not a NinjaScript thing.
[That is, just know thatthisis a programming concept in C# and NinjaScript is just a programming framework that happens to use it.]
Second, when youâre programming in an object-oriented language, which C# most definitely is, it helps to think in terms of classes â because almost every variable you deal with is said to be an object of a certain class.
[In the old days, weâd say a âvariable of a certain typeâ, so the new object-oriented way is to say an âobject of a certain classâ. The classic idea of a âvariable of a certain typeâ does not go away, but saying an âobject of certain classâ is the new high level way of basically saying the same thing. After all, a class is just another kind of type. That is, the older concept of âtypeâ is still superior to that of âclassâ.]
Ok, in C# it really helps to think of everything as an object, which just means an object has a class type. Remember, the class is like a blueprint, it can have data and functions (which we call methods) that can be called to act on that data. An âobjectâ is what is created (in memory) when you say (in code) I want a thing to be created and I want it to represent a certain class.
The thing that is created is created with code, and the result is stored in memory.
But the thing that is created is not called a thing.
Itâs called an object.
-=o=-
Letâs look at an example.
Inside your strategy (or indicator), letâs say you have,
EMA myEMA;
and later you do,
myEMA = EMA(200);
That line meansmyEMAis a variable, and an instance of theEMAclass is being created, meaningmyEMAbecomes a reference to an object of classEMA. (Saying âreference to an objectâ gets old, so we usually just say âinstanceâ, and we usually donât say âcreatedâ, we say âinstantiatedâ.)
[EDIT: In pedantic nerdy circles, youâre more likely to see âinstance of a classâ, not âobject of a classâ â but I donât think the difference matters that much. To me, the âinstanceâ is accessed via the reference stored in the variablemyEMA, but the thing immediately behind that reference is, duh, an object â it doesnât really matter how you say it â at a high enough level the terms are fairly interchangeable.]
Remember, an object is just pieces of data all grouped together via code (either yours or somebody elseâs) but that code can also have methods that can be called on that data. In C#, we say the reference to that object is stored in your variablemyEMA, aka, the âinstanceâ.
Ok, still with me? Now, letâs talk aboutthisand what it means.
Recall I saidmyEMAis a reference? Well, when dealing with objects, you have to have a reference to it, meaning a variable has to contain it â meaning you, the programmer, chose some variable name and assigned it a value.
But letâs say inside the class that you are writing (such as your indicator), you need a reference to yourself. Yep, for some reason, you need a reference to the current object (because somebody above you is calling your indicator, so your indicator code is currently running), and you need to pass a reference to yourself to somebody else who needs it.
Thatâs whatthismeans. Itâs a reference to the current object that is running, and when you passthisto somebody else, that somebody else now has a reference to the object that called them, just in case they want to call back into the calling object to get some data or call some method of the calling object. Yep, this need is rather common in object oriented programming. In fact, the need to get a reference to yourself is so common, Microsoft madethisa predefined keyword.
And there you have it! In summary,thisis a predefined variable name which always contains a reference to the object that is currently running. Under the hood, the C# execution environment is constantly adjusting the value ofthisautomatically.
Letâs dissect these 3 lines of code,
x = new Series<double>(this);
y = new Series<double>(SMA(BarsArray[0],1));
z = new Series<double>(SMA(BarsArray[1],1));
Iâll try to reveal the magic behind the curtain.
Unlike theAddOnplugin, theIndicatorandStrategyare always associated with bars â usually these bars come from the chart itself, but they donât have to. (Stop and think about that a second: that the bars input can come from anywhere, not just a chart, should blow your programmerâs mind â thatâs quite a software architectural achievement. That decoupling ultimately helps to provide some extreme design flexibility as well as the basis for some amazing capabilities, but I digress.)
When you specifythisin line 1, youâre asking for a new object of classSeriesto be created, and for that object to be associated with the bars the indicator is already associated with, aka, the bars on the chart. Thatâs what thethisargument is doing â it allows theSeriesclass to call back into your currently running indicator instance to get the bars associated with that instance, and make a newSeriesobject that is synced to those same bars, which is all stored as a reference in the variablex.
In line 2, itâs the same thing. Why? BecauseSMA(BarsArray[0],1)is a way to reference the bars associated with thatSMAindicator instance , which is created using bars fromBarsArray[0]. ButBarsArray[0]is (as you know) just another way to say the bars on the chart. Thus, bothxandyare data series synced to the same bars(*).
[EDIT: (*) Usually this is true, but specifyingBarsArray[0]forces the series to be associated with the primary bars of the chart, whereas specifyingthismeans the primary bars normally associated with the indicator instance could have been hijacked if you changed the input data series of the indicator when you added that indicator to the chart. Changing the input data series of an indicator is a rather advanced need, and probably not that common, so like I said, theyâre usually the same thing.]
Ah, finally, line 3. So, whatâs going on?
Itâs simple. The Series class is reaching into (er, I mean, calling back into) theSMAindicator to get the bars associated with that indicator instance, but in the case of line 3, the bars are coming fromBarsArray[1]â so a new instance of theSeriesclass is created and it is synced to those bars fromBarsArray[1]â and a reference to this new object is stored in the variable z.
Make sense?
