Why is it "strongly suggested" to define enums outside of a Strategy?

[EquityTrader]

Hello,

In the "Miscellaneous practices" section of the "NinjaScript Best Practices" web page, the subsection titled "Creating user defined parameter types / enums" states:

"When creating enums for your NinjaScript objects, it is strongly suggested to define those outside the class (emphasis is my own) and in a custom namespace. A reference sample providing all details could be found here." where the "found here" link is to the "Creating a user-defined parameter type (enum)" code example at https://ninjatrader.com/support/help...ned_parame.htm

Why is it strongly suggested to define enums outside of a NinjaScript Strategy that uses it?

Could anything bad happen if an enum was defined as a nested type of a Strategy?

I ask because I have multiple Strategies where the "same" enum (for example an enum that contains the 12 months of the year, which are exact copies of each other) is defined as a nested type of each of the Strategies, and since each of the enums are nested types of separate Strategies, they are unique types and so won't cause a compilation error due to the same enum being defined multiple times. Furthermore, I can share all of these strategies with other people without them getting a compilation error that either says that the enum type is missing or that the enum type is defined multiple times. In other words, defining enums as nested types of Strategies has the advantage that it makes the Strategies easy to deploy, since every nested enum type is guaranteed to always be defined exactly once.

Thanks in advance!

EquityTrader

[Zigfried]

I seem to remember seeing a post that eluded to enum location problems when you are compiling your work for distribution. Personally, I put all of my enums and common functions into a single indicator that I commonly use. I haven't had any problem with that approach, but I don't compile for distribution.

[NinjaTrader_ChelseaB]

Hello EquityTrader,

The enums should be in a custom namespace below the indicator class (not inside of).
This prevents issues with generating the NinjaTrader generated code at the bottom.

Having the enum declared within the strategy class would be only available within the indicator or strategy class and can sometimes cause issues with exporting.
With indicators this would not allow the enum to be used as a public parameter when hosted in a host strategy, as the enum will not be available to the host.

I prefer to use the name of the indicator with _Enums.

namespace MyCustomIndicator_Enums
{
public enum MyEnum
{
Enum1;
Enum2;
}
}

Below is a link to the reference sample that demonstrates.

https://ninjatrader.com/support/helpGuides/nt8/creating_a_user-defined_parame.htm

[EquityTrader]

Hello NinjaTrader_ChelseaB,

Thank you for your answer. It will definitely help people who want to know the answers to my questions, but for Indicators rather than Strategies.

My questions were specific to Strategies and I still need help with my questions as they pertain to Strategies, specifically to Strategies for my stated use case.

Also, you and I are on the same page about how to implement your proposed solution for Indicators rather than Strategies, because the sample to which you linked was the same as the one to which I linked in my original question. I completely understand the code in the sample to which we both linked.

My original question posed my specific challenge, which would not be solved by your proposed solution:

I have multiple Strategies where the "same" enum (for example an enum that contains the 12 months of the year, which are exact copies of each other) is defined as a nested type of each of the Strategies, and since each of the enums are nested types of separate Strategies, they are unique types and so won't cause a compilation error due to the same enum being defined multiple times. Furthermore, I can share all of these strategies with other people without them getting a compilation error that either says that the enum type is missing or that the enum type is defined multiple times. In other words, defining enums as nested types of Strategies has the advantage that it makes the Strategies easy to deploy, since every nested enum type is guaranteed to always be defined exactly once.

When you read the quote above, you will understand the problem with following your advice, but for a bunch of Strategies that all need the same enums. Namely, if a given enum that is needed by all of the Strategies is defined in its own namespace at the bottom of every Strategy ".cs" code file, the C# compiler will complain that the same enum type is defined more than once.

Given the major deployment advantage of defining enums as nested types in Strategies as I explained above, I have questions about your sentence that mentioned Strategies specifically:

Having the enum declared within the strategy class would be only available within the indicator or strategy class and can sometimes cause issues with exporting.

Other than exporting issues, could anything else bad happen if an enum was defined as a nested type of a Strategy (not for an Indicator), if it is OK for the enum to only be available in the Strategy?

You mentioned problems with Exporting. Could you please give an example of a Strategy with a nested enum type that could cause problems with Exporting? I was able to export my strategies both as code files and as assemblies, and import them on a different computer without problem. I am also able to define input parameters in my Strategies that cause nice drop-down lists to appear in Strategy Analyzer back-tests and when applying Strategies to real-time charts and that cause nice multi-select checkbox lists to appear in Strategy Analyzer optimizations, and all of my selections of my preferred input parameters can be nicely serialized to and deserialized from disk so my preferred choices for the enum-based input parameters can be remembered between NinjaTrader 8 sessions.

Thank you very much for your help,

EquityTrader

[NinjaTrader_ChelseaB]

Hello EquityTrader,

I am not understanding. If the enums are in different name spaces they will not conflict.

If you want to share the enums with multiple scripts, put the shared stuff in a separate file in the Addons folder.

I am not suggesting that you nest the enums, but if that's what you want to do, that's up to you.

[EquityTrader]

Hi Chelsea,

I still need your help. I really need to know what can go wrong with nesting enums in a Strategy, because using your solution but for my specific use case as outlined in detail in my previous post has the following serious problems:

If I used the solution to which you linked, but for let's say 100 Strategies instead of 1 Indicator, and I copied and pasted the separate namespace code that is below one Strategy in one Strategy ".cs" code file into the others, the code would not compile because the enum in the first file and the enum in the 99 copied and pasted namespaces in the other 99 files would be considered to be the same type but re-defined a total of 100 times, when only 1 time is allowed.

On the other hand, if I used the solution to which you linked, again for let's say 100 Strategies instead of 1 Indicator, but if instead of copying and pasting the separate namespace code I slightly changed the names of the namespaces in all 100 Strategies to ensure that the enum defined is considered to be a different type to avoid the compilation error just described, this would not only be a lot of work to do once and to remember when I am maintaining the code, but it is even more work because in the example you posted, the namespace has to be referenced inside of the Strategy as well so all references to the enum in each of the 100 Strategies' namespaces with slightly different names would also have to be different.

Finally, having the 100 Strategies sharing the enum in a common file as you described would also not be a great solution for my use case, for two reasons:

1. First-time deployment would be more complicated for end users than simply copying and pasting a single ".cs" code file.

2. Deployments of new versions of say 20 of the 100 Strategies but not the other 80 become more complicated and fraught with risks because each of the Strategies now has an external dependency on code in another code file. Updating the enum in the common file would affect all 100 Strategies, instead of only effecting the 20 Strategies with updated code that need an updated enum.


Hopefully you can now see why your proposed solution doesn't work for my use case, and why nesting the "same" enum in 100 Strategies (i.e. visually the same in the code but different enum types from the perspective of the C# compiler) is perfect for easy deployment and solves serious versioning issues.

This is why I really need someone from your team to answer the two questions I raised in my last post, so that I can decide if nesting the "same" enum in 100 Strategies will cause any problems.

Other than exporting issues, could anything else bad happen if an enum was defined as a nested type of a Strategy (not for an Indicator), if it is OK for the enum to only be available in the Strategy?

You mentioned problems with Exporting. Could you please give an example of a Strategy with a nested enum type that could cause problems with Exporting?

Thank you for your patience and consideration of my post above.

EquityTrader

[NinjaTrader_ChelseaB]

Hello EquityTrader,

"and I copied and pasted the separate namespace code that is below one Strategy in one Strategy ".cs" code file into the others" this is not making sense.

You wouldn't copy and paste this into each script. You would put this in a separate file in a custom namespace to be accessed by all scripts.

This would also be included with your export. You don't have to, and should not be, copying and pasting anything. The client should get an export that includes the scripts you want to share them, including the file with the enums.
They should be going to Tools -> Import -> NinjaScript Addon and selecting the importable file. There should be no other steps. The client should not open the .zip.

I am not suggesting that you copy and paste the code into multiple scripts in the same namespace. But if you want to localize the enums then make a custom namespace in each strategy.

It's one or the other. Share them or don't. If they are shared, updating the enum with new values won't hurt anything. As long as the old values exist, nothing is broken.
If you have the code open in VisualStudio and you change one of the enum names, you can click the lightbulb to make that change to any other script that is using the same enum in the same namespace. This only takes two clicks.

With Strategies, these are not as likely to have issues with nested enums. However, do not get in that practice. Take the advice we are giving you, write it standard that way every time and you won't have a problem. If you want to copy the code to be nested, this completely up to you. If that's what you want to do then do it. If you have issues, then stop doing it.


Unfortunately, no, I am not understanding why the solutions I have proposed will not work.

[EquityTrader]

Hi Chelsea,

Thank you for your help today.

I will think about everything you said and make a design decision one way or the other.

Everything I am doing is machine-to-machine instead of requiring the user to manually import code that I manually export. This is why I kept trying to get information out of you regarding what can go wrong with nested enums in Strategies, since unless there is something that nested enums in strategies break that I have not encountered yet, they really are the perfect solution for both deployment and versioning of enums needed by Strategies if it is important that every Strategy ".cs" code file is a self-contained package that can be updated by copying a single ".cs" file from one directory to another without affecting any other strategy.

Anyway, thanks again for all the help today,

EquityTrader

[NinjaTrader_ChelseaB]

Hello EquityTrader,

If you want to do stuff that NinjaTrader does not support, that is up to you.

Our Scripting Support team won't support that.

We support what we have created, which is importing from Tools -> Import -> NinjaScript Addon. Anything else we cannot help with.

[EquityTrader]

Hi Chelsea,

OK. Thanks again for your help yesterday.

EquityTrader