global namespace error already contains defination

[koganam]

Updating this thread here as we have lately seen issues following this approach. If you export as an assembly, your enums declared in their own namespace may not import correctly on another machine. Official recommendation on enum placement is shown in this sample:
http://www.ninjatrader.com/support/f...ead.php?t=3420

If it is not asking too much and the indicator on which you claim to see such an issue is not distribution-restricted, may I have a copy, so that I can see this for myself, because I really think that you are getting it backwards.

Namespace clashes that cause import errors, in my limited experience, have always been in the global namespace, precisely because it is the only namespace that is likely to have the same name as another ("global" is global, and ipso facto, default).

Of course, if the same enum is defined in two separate files, in the same named namespace, then you have the same clash situation. That is only to be expected: a clash is a clash, in any namespace, not just the global one. In which case, the problem is not in declaring the enum in its own namespace; the problem is still in the clash in the namespace.

[NinjaTrader_RyanM1]

It can be seen with a simple example, following the suggestions earlier in the thread for enveloping in custom namespace. I'm updating here to inform of potential issues that can be seen with this approach, so it's counter productive to share further bad examples here. If you need the exact files I'm using to show this problem, please send a note to support 'at' ninjatrader 'dot' com attn: RyanM and can share that route.

[koganam]

It can be seen with a simple example, following the suggestions earlier in the thread for enveloping in custom namespace. I'm updating here to inform of potential issues that can be seen with this approach, so it's counter productive to share further bad examples here. If you need the exact files I'm using to show this problem, please send a note to support 'at' ninjatrader 'dot' com attn: RyanM and can share that route.

I investigated this, and while it is true that if you envelope your entities into a custom namespace you will probably get an error when you try to import an indicator or strategy that is exported as an assembly, the reason is pretty straightforward once you examine what is happening.

Here is the skinny. When you create an assembly, it seems that NinjaTrader separates the class code from the magic code that it puts in at the bottom of indicators. Now, this may just be a duplicate, or a complete separation: it is not really relevant. Anyhow, NT creates a DLL, obviously containing the class whose code you wish to hide, and a separate .cs file that contains what looks like a duplicate of the magic code that it would normally put at the bottom of the source file.

Therein lies the issue. NT, creates that file on the assumption that you are following the instructions to pollute the global namespace, so does not create a "using" directive for your namespace. Therefore, if any of your input parameters involve an object defined in the custom namespace, it loses its reference.

To correct the issue, all you need to do, is open the zip file, edit the .cs file by adding the "using" directive, and everything is tickety-boo. Remember to only add the "using directive at the top of the file: do NOT touch the NT generated code, per the warning that NT puts in the file.

Incidentally, this cause of the problem, as it involves assumptions involving any additional "using" directives, means that you get the same problem if you "use" any other system namespace that NT does not provide by default when you use the wizard to create the indicator. For example, if you need to check for the existence of a file, you would have to have a "using" directive for the "System.IO" namespace. This will NOT be included in the .cs file that NT generates, so you will have the same problem if the filename is a required input, per the signature of the indicator, if it were to be called from another indicator. If your object in the non-generated "using" namespace is not a required input, it does not show up in the magic code, so the point is moot.

As a passing matter, someone PM'd me to ask why I am so paranoid about polluting the global namespace. Well, the humorous reason I guess is that, because, with my Professor, polluting the global namespace led to an automatic loss of a full grade. More importantly, EVERYTHING defined in the global namespace should be in one file, not scattered over who knows how many files. That is because that is the most efficient way to ensure that that new developer you hired yesterday comes quickly up to speed. She should see everything that affects everything else, all loaded from the main project files, not have to be making searches to find where and how things are defined.

[darmbk]

Hi all,

Back story:

I previously wanted to write my first enum and followed the NT suggested solution linked to here by NinjaTrader_RyanM in the posting at 10-28-2011, 02:14 PM above. This solution is shown in SampleUniversalMovingAverage.cs. Using this solution, I ran into the namespace issue mentioned in this thread. From reading this thread in the aftermath, it is now my understanding that the NT solution "pollutes the global namespace". In my case, I have 11 consecutive versions of a strategy coded up, which contain the same enum declaration. Up until version 10 there was no issue, then at version 11 the namespace issue arose out of the blue. In trying to find the issue I worked backwards, trying to recompile earlier versions, all of which previously compiled and ran without error, but now they complain about the polluted namespace.

To completely remove the error I had to go back through the versions that had failed to compile today and add in uniquely named namespaces into each and then recompile.

Questions:

[1] Why is NT suggesting this method for declaring enums if everyone agrees it is flawed? Is there a good reason for this method if otherwise it pollutes the global namespace and thus is stated to be very bad coding.

[2] How can one delete enums from the global namespace.

[3] This thread explains that creating a namespace with a unique name (e.g. the name of the strategy file) is the only safe method of declaring enums. Is it true that this is the way everyone is declaring enums in NT?

Thanks in advance,
darmbk.

[NinjaTrader_JC]

Hello darmbk,

1. This recommendation is ensure when Exporting code in NinjaTrader and importing this on to a new machine that does not have the namespace it would cause issues. Declaring it in a separate namespace would require you to manually include the namespace before the said Indicator/Strategy to prevent issues.

2. If you have the enum declared globally, in one NinjaScript file you may either remove the declaration of the enum in your other NinjaScript files and keep this only in one or use the own separate Namespace for the enum declaration and remove all other declarations globally.

3. This is mostly person preference on as both will work, but to keep things separate and to create less confusion it is more accepted. Keep in mind the issue in question 1 if you are going to export the code.

Let us know if you have any further questions.

[darmbk]

Thanks JC,

[1] Could you give an example of what this means? Is it that if I create a strategy and send it to you and you try to run it then it will complain? Why wouldn't you simply compile it and then the namespace would be ok? I appreciate that I'm missing something here.

Thank in advance,
darmbk.

[NinjaTrader_JC]

Hello darmbk,

This is usually due to the namespace being in another file so what this would mean is that for example if you had a separate namespace declared called "EnumVariables" and it was its own separate file then when you export your strategy, you will have to select that "EnumVariables" file including your strategy so that when another person like myself import your files that we have access to it.

Let me know if you have any further questions.

[Ducman_nl]

Thanks, makes things more clean