One of the things we are going to focus on in the next release of RightEdge is ease of use. Some of the feedback we have been getting is that it can be hard to figure out how to do what you want to when writing a system, and sometimes the interfaces are outright confusing. So we are planning on making some changes to our interfaces to make system writing easier. Listed below is what we are thinking about, and we welcome your feedback on these changes or anything else you think could be improved.
When writing a system, you will create a "symbol strategy" class. One copy of this class will be created for each symbol. Most of your system logic will probably go in this class. Code that would previously have gone in your System's NewSymbolBar method will go in your symbol strategy's NewBar method. This will make it much easier to store symbol-specific data: instead of having to manage a dictionary and a separate class to store this data, you can simply declare a field in the symbol strategy class.
We will make it easy to access the data you want in the symbol strategy class. For example, there will be a Bars property which will return the list of bars for the current symbol. So where previously you had to specify something like SymbolBars[symbol][index], you will be able to use just Bars[index]. Indicators will work the same way, and for DnD indicators we are planning on automatically creating properties for each one, so instead of Indicators["SMA50"][symbol][index], you can just use SMA50[index].
You will still be able to have a System class that there is only one copy of. You can use it to store non symbol-specific information, or put all of your logic in it if you don't want to use a symbol strategy class. We're also not sure that "symbol strategy" is the best name for this class, so let us know if you have a better idea!
We are going to make it easier to open and modify positions, and to manage orders. The OpenPosition method will return a Position object instead of ReturnValue<string>. The ReturnValue model may be a good idea for a team of programmers, but it is confusing and hard to explain to new users who may be novice programmers. The Position object will have an Error property which contain the error string if the OpenPosition call was not successful, and will be null if it was.
The Position class will include properties and methods that will allow you to use the Position object directly instead of having to pass the position ID to a method in the PositionManager class. Examples of such members are CloseAtMarket(), SetProfitTarget(), SubmitOrder(), ProfitTarget, Orders, etc. Inside a symbol strategy, you could use the following code to close all open positions for a symbol:
foreach (Position pos in OpenPositions)
The Order class will be changed in a similar manner to the Position class. (Actually we will rename the current Order class to BrokerOrder, and write a new Order class with the functionality we want. The BrokerOrder class will still be used by broker plugins and internally by the position manager.)
Reversing Series Order
We are not sure if we are going to make this change because it is a major change which would probably require changes to all current systems and indicators. If we do make this change then index zero would be the most recent value for indicators, bar lists, or other series, instead of the oldest value.
Systems and indicators are constantly accessing the most recent value, or the value from n bars ago. They rarely, if ever, care what the very first value of a series was. So it makes a lot more sense to use Bars for the current bar and Bars for the previous, instead of Bars[Bars.Count - 1] and Bars[Bars.Count - 2]. We think it will be easier for new programmers to understand.
This change will also make it easier to add support for running simulations on very large data sets down the road. Right now, if you want to run a simulation on 1 minute bars for the past 10 years, all that data has to be loaded into memory, and it may not all fit. Eventually we would like to support loading the data on demand and releasing it once it is not needed anymore. If your system only needs to look at the previous 200 bars, then any data prior to that can be released. This will be easier to manage if we change the way the series are indexed.
Please let us know what you think. All of this is subject to change of course. While the changes we are planning are fairly major, we will leave as much of the existing functionality in place as we can. You probably will have to make some changes to your existing systems, but we certainly don't want to force you to rewrite them entirely.