Namespace problem

[ETFVoyageur]

I have some private demo scripts, so I thought I would put them in a nested namespace of NinjaTrader.Indicator to keep them out of the the NinjaTrader.Indicator namespace.

That all works fine, except the Magic Code has hard-coded namespace stuff instead of allowing access via "using" statements.

For example, if I place my code in NinjaTrader.Indicator.Demo, it will not work because of Magic Code lines like:

public Indicator.DemoStaticFunction DemoStaticFunction()

Note that assumes my function is in Indicator, while it really is in Indicator.Demo.

I know that for now that only answer is "Don't do that", and I won't.

I would like to ask that, for the future, the Magic Code depend on "using" statements being correct so that one can indeed use nested namespaces.

Would that case any problems?

--EV

[NinjaTrader_Brett]

Hello,

I will forward to development for there consideration. Thanks for the suggestion!

[NinjaTrader_Brett]

Hello,

Further clarification here. Creating a custom namespace is not possible in NinjaScript. It is possible in C# but not NinjaScript therefor as your aware outside of our level of support we provide.

[ETFVoyageur]

No, I was not aware that creating a nested namespace would be unsupported.

I know that everything has to be in the Indicators namespace, but it never occurred to me that did not include nested namespaces.

Thanks for the clarification -- now I know it is unsupported. Since it seems like a very reasonable thing to do, and since it seems easy to allow, I'd like to suggest that it become supported.

I'm hoping that it is as simple as taking the hard coded namespace stuff out of the Magic Code, and expecting compilation to work because of "using" lines.

--RV

[NinjaTrader_Brett]

Thanks for suggestion!

[koganam]

Hello,

Further clarification here. Creating a custom namespace is not possible in NinjaScript. It is possible in C# but not NinjaScript therefor as your aware outside of our level of support we provide.

Say what? Many of us have been isolating enums into newly declared namespaces for a while now, because we would rather not pollute the global namespace, and even Intellisense honors the namespaces. Did I misunderstand what you just wrote?

There are few absolutes in programming, but it is generally conceded that polluting the global namespace is bad.

[ETFVoyageur]

Say what? Many of us have been isolating enums into newly declared namespaces for a while now, because we would rather not pollute the global namespace, and even Intellisense honors the namespaces. Did I misunderstand what you just wrote?

There are few absolutes in programming, but it is generally conceded that polluting the global namespace is bad.

The issue is not those separate namespaces. They work fine.

The issue is that I tried to put my demo code in a namespace that was nested under Indicator. That canot be done with the current NT, because the Magic Code has some hard-coded namespace stuff. I am requesting that they give up that hard-coded stuff and depend on having the correct "using" directives. Then we could nest namespaces under Indicator.

--EV

[koganam]

I was seeking to clarify NT_Brett's assertion: "... Creating a custom namespace is not possible in NinjaScript..."

That seems globally declarative to me; not just related to nested namespaces.

[NinjaTrader_Brett]

Hello,

We cannot support any custom namespace. You must use the namespace provided in NinjaScript. even though this is C# programming and you can do it. It is out of what we can support. NinjaScript is used here as a method to submit order and program a strategy in the strategy namespace. Adding custom namespaces is something that we cannot support, even though it should work if an unforeseen issue arises due to it we cannot support it.

Thank you.

[ETFVoyageur]

Hello,

We cannot support any custom namespace. You must use the namespace provided in NinjaScript. even though this is C# programming and you can do it. It is out of what we can support. NinjaScript is used here as a method to submit order and program a strategy in the strategy namespace. Adding custom namespaces is something that we cannot support, even though it should work if an unforeseen issue arises due to it we cannot support it.

Thank you.

Brett,

I take it this means today, and does not mean you will not consider my suggestion for the future. Right?

-----

As to today, there is an issue that V7 created -- where to place enums for enum parameters. What is your advice on where to place them so that they do not pollute the global namespace?

That's what some of us are using custom namespaces for. If you have a better idea, I'd be happy to take you up on it. But we do need some way to get those enums out of the global namespace. Polluting the global namespace is evil.

Thanks,
EV

[NinjaTrader_Brett]

Enums must go in the global namespace. This is demontrated in this supported NinjaScript Sample: We do not support anything else.

http://www.ninjatrader.com/support/forum/showthread.php?t=3420

[koganam]

With all due respect, when your power users point out a potential problem as large as namespace collision, and get a response delivered in the manner of a ukase, it leaves a sour taste in the mouth, and detracts from what is otherwise a very professional appearance.

[ETFVoyageur]

Ouch!

I saw that example and just assumed it was over simplified as a demo, or else written by someone without commercial programming experience.

Having multiple suppliers contending with names in the global namespace is really evil. Two suppliers can collide, and no one will know until indicators from both suppliers are installed on the same system. There is no way for the supplier to catch this during testing, and there is no guarantee that even extensive beta testing will catch the problem.

I personally create a namespace that is the same name as the indicator. That has the advantage that it is guaranteed to be different than any other indicator -- mine or anyone else's. I could see some suppliers wanting to have all of their indicators share one namespace, though, and I have no problem with that. I just do not want them in my namespace.

The good news is that AFAIK this very simple use of a namespace has no potential for causing a problem. It is zero work for NT -- just agreeing that this is good practice, rather than calling it unsupported. And fix Josh's example to use a namespace for his enum.

Please put in a request that there needs to be some supported way to get those enums out of the global namespace. I do not care what the mechanism is, but I want my symbols to be somewhere that is guaranteed not collide with anyone else. My own namespace is the most obvious answer.

--EV

[NinjaTrader_JoshP]

The method provided in the reference sample is the only method we can support. If you want to do otherwise you are free to attempt, but we cannot make any guarantees on what will/will not work in those cases.

As much as we would like to support every single caveat of C# we unfortunately are not able to and have drawn the line as to what we can cover and what we cannot. Just because it is not covered by us does not mean you cannot do it. You can always explore in any direction you please, we just unfortunately will not be able to provide you with any guidance down those venues. Thank you for your understanding.

[ETFVoyageur]

Josh,

I do not understand "the only method we can support". This is one thing that costs you no work at all. There is nothing to support. There is no cost to you. Zero. Zip. Nada. And it heads off a very real problem before it can get started.

What it does take is you agreeing that it is a good idea, and showing it in use in your demo (and any other place that talks about how to use enum parameters).

I cannot imagine any serious professional programmer who wants his symbols sharing a namespace with those from another supplier.

Is there any good reason for not agreeing to this?

--EV