Suggestion - Inherited indicator public properties not created

[MicroTrends]

This is a request for a pre-compiler - code editor change.

The issue is that with derived classes the public browsable properties are not scripted in the constructor in the auto generated script region . so its constructor signature does not match what is really there.

Please see attached indie:

The end result misses the base.Period property.... which is available via reflection propertyinfo on "this".... you would simply script properties by attribute.

#region NinjaScript generated code. Neither change nor remove.
// This namespace holds all indicators and is required. Do not change it.
namespace NinjaTrader.Indicator
{
publicpartialclass Indicator : IndicatorBase
{
private ModSMA[] cacheModSMA = null;
privatestatic ModSMA checkModSMA = new ModSMA();
///<summary>
/// Derived from the SMA class
///</summary>
///<returns></returns>
public ModSMA ModSMA(int threshold)
{
return ModSMA(Input, threshold);
}
.........

///Desired Generated code
public ModSMA ModSMA(int threshold, int period)
{
return ModSMA(Input, threshold, period);
}

The obvious way round this is to code the public properties in again - overlaod them and use the base class properties inside - but the compiler syntax checker thinks this is a self referencing issue -recursive property

http://www.screencast.com/users/MicroTrends/folders/Jing/media/408e7184-41ce-4380-b7af-6112d03c9581

Please can we chane the editor so this use of inheritance works - it will save me potentially weeks of coding over the project lifecycle.

[NinjaTrader_Bertrand]

Thanks for the detailed feedback MicroTrends, we'll look into it.

[MicroTrends]

My Pleasure it will be sersiously amazingly, easy and quick for me and others to build stuff if this is resolved....:-) 1 change in a base class and no further changes needed - currently i may have to change up to 30 modules...:-)

[arnonmoscona]

With NJ7 you should be able to use C#3 extension methods for common code instead of a base class. You would need to repeat all your properties in each of the indicator instances, but your logic will still be in common code (faking multiple inheritance)

[MicroTrends]

"...You would need to repeat all your properties in each of the indicator instances..."

Not sure if there is any benefit there over using interface inheritance and a class reference/wrapper
Also perhaps you would then have create an object context and pass it into the common code - so that methods that were referencing this.method now reference thisContext.method/ property etc

Properties have to retyped as a public wrapper for the NSWrappers code to generate
and methods changed.

I can see a use for it in getting around the compile time references for indicators from the class that inherits from the strategy class. so you can create an object of type strategy and pass in the context of the actual strategy instance.

With the true inherited pattern it was less code - to get around the issues by making the private fields public and referencing them in the property

eg

MyProp1
{
get{ return base.myProp1;}
}

- less code - dont like it much as a geek but it worked fine. Only the properties have to retyped as a public wrapper for the NSWrappers code to generate - methods dont need refactoring.

Another way was to simply change the public property name!
That required no changes to fields...

[arnonmoscona]

Yes. I see your points.
Another approach is to just implement the whole common code as a separate class, if its state is fully contained and does not interact with the rest of the indicator. Then just hold a reference to that. Still need to create the properties (don't see anything around that), but at least there's exactly one class (no interface, static class as for extension methods)

[MicroTrends]

Thanks for your input.
In theory surely it would be far less code to use a base class inheriting from indicatorbase or strategybase...
Using inheritance in this case should be 1 line of code on the class declaration - but alas it is not... so i break a few design rules/ideals....

public abstract class MyNewIndicatorBase: Indicator
{
publicint zoneSettingID=0;
privatestring zoneSettingName="";

[Description("Zone Setting Name - the user defined name for the Zone Setting ID")]
[Category("MT Zone Setting")]
[Gui.Design.DisplayNameAttribute("MT - Zone Setting Name")]
publicstring ZoneSettingName
{
get { return zoneSettingName; }
set {zoneSettingName=value; }
}

[Description("Zone Setting ID - the Setting ID to save or loads")]
[GridCategory("MT Zone Setting")]
[Gui.Design.DisplayNameAttribute("Zone Setting ID")]
publicint ZoneSettingID
{
get { return this.zoneSettingID; }
set{this.zoneSettingID=value;}
{
this.zoneSettingID=value;

}
}
}

}

public class MyNewIndie : MyNewIndicatorBase
{


/// This is only neccessary as NS Wrappers Generator does not use iterate properties of object - perhaps only pasrses the script file etc... the other property is not needed by the class factory parameter lists - eg when a strategy creates the indicator instance and starts it etc...

[Description("Zone Setting ID - the Setting ID to save or loads")]
[GridCategory("MT Zone Setting")]
[Gui.Design.DisplayNameAttribute("Zone Setting ID")]
publicint ZoneSettingID
{
get { return base.zoneSettingID; }
set{base.zoneSettingID=value;}
}

}


The issue is that it's a pain to have write the public properteis out again - so the NS Wrapper code gen macro picks them up - it doesnt know to iterate through the object property collection and generate code by atribute etc - maybe it just reads the script instead of using reflection which is a lot easier?

Then the other issue was the pre compiler checks think that
this.Prop is the same as base.Prop - reports a self referencing code block.
hence the need for the public field above

I would be interested to see your proposed pattern to replace the above using extensions..

thanks for your reply

[arnonmoscona]

I agree. But also bear in mind that the inheritance approach, which would be ideal under most circumstances, also has a shortcoming. (had it worked) It limits you to reuse code only within the IndicatorBase hierarchy. By packaging your common code in a separate "helper class" you can use it in indicators, strategies, and market analyzer columns. You do need to repeat properties, which is certainly tedious, but you have more reuse...

Not to say that I wouldn't want inheritance to work. I would... but we have what we have (for now at least)

[MicroTrends]

yes a lovley helper class than can be combine using multiple inheritance - oh damn!

[MicroTrends]

Class extensions in this case i feel are not a suitable design pattern- based on my previous usage - surely better for extending a String Class for example with a method of some sort...when you dont ahve access to the code source for compilation...?
but if you have an example where this can be used versus inheritance, interface inheritance then please do i would love to see it...

In answer to
"...But also bear in mind that the inheritance approach, which would be ideal under most circumstances, also has a shortcoming. (had it worked)..."
Yes it did work fine- the solution was below - simply expose the private fields in the base class or refactor the property names in the top level class. Less code more robust - less maintenance.

"It limits you to reuse code only within the IndicatorBase hierarchy..."
Only by bad design perhaps? That was also avoided by designing the class hierarchy with a reuse view in mind at the outset by using classes which implemented interfaces, the building specific class types using abrstact class inheritance and interface muliple inheritance - patterns - ie inherit class A, create class b and write a Wrapper so that class AB created from A and B is inheritable with seperate reusable atomic parts...

The Class Extensions to the best of my knowledge will not work for this, as it only concerns methods? So yes i agree with the basic C# .Net design principles - but yes i did break some rules... public fields...

By combining the pattern of single inheritance and then interface inheritance one can implement C= AB hierachies very cleanly - but its verbose.

In the code base - common properties and methods are kept in seperate helper classes which implement interfaces for ease of testing and code building etc.
so the pattern of write once and use many is implemented, but that means writing more code to implement that pattern still as you say.. mutltipe inheritance would have done the job in seconds but that took days to build if not weeks... but is solid and wont cause issues later!

So in the actual indicators in question - the public properties in the indicator base class reference data, business objects and common helper classes, however some functionality is specific to indicator classes to make them containt certain type of unique inheritable behaviours, events, methods and some properties...
So we end up with an inheritable classes such as mean reversion signals indicator base class or trend signals base class...
The only issue was code editor, the need to write the properties again in the top level class due to the NS Wrappers - then the compiler check not understanding code syntax.

The reason this solution is the correct route for me now is that the code base is written this way already - and would need refactoring extensively... when a simple refactor of property names at a top level class is all that is required.

Another reason is that best practice for developing in C# depict the route i took.
For more details of programmin in C# using inheritance this is a good start:

I would say i was seriously let down by C# when it hit the main stream without MI - but it saves all the lunacy we used to see in projects when coders misused it or designed rubbish class hierachies - shame we can't choose as the C# language (javascript?) is very nice... Anyone who was a delphi or c++ user before 2001 - will know that we now type much more code...in C# when dealing with infernal SI...

Some resources for anyone confused by the above

Inheritance programming:
http://msdn.microsoft.com/en-us/library/ms173149.aspx

Inheritance, together with encapsulation and polymorphism, is one of the three primary characteristics (or pillars) of object-oriented programming. Inheritance enables you to create new classes that reuse, extend, and modify the behavior that is defined in other classes. The class whose members are inherited is called the base class, and the class that inherits those members is called the derived class. A derived class can have only one direct base class. However, inheritance is transitive. If ClassC is derived from ClassB, and ClassB is derived from ClassA, ClassC inherits the members declared in ClassB and ClassA.



For Class Extensions:

http://msdn.microsoft.com/en-us/library/bb383977.aspx

Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. Extension methods are a special kind of static method, but they are called as if they were instance methods on the extended type.



Limitations:

• Extension Methods have to be implemented as static methods and in static classes (inside a non-nested, non-generic static class to be more precise).

• You can use extension methods to extend a class or interface, but not to override them. An extension method with the same name and signature as an interface or class method will never be called. At compile time, extension methods always have lower priority than instance methods defined in the type itself.
• Extension methods cannot access private variables in the type they are extending.

Here is what MSDN says on this subject:
“Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible.

[MicroTrends]

Ok even better- solution no need to change anything - other than explcitly declaring the properties again in the child class and using the New keyword - prevents the compiler precheck moaning about recursive properties....

public new int TradeFilterMode
{
get { return base.TradeFilterMode; }
set { base.TradeFilterMode = value; }
}


You wont need to do this in a strategy - only an indcator - but alos in instances where you want to hide and replace the property with a different code..etc

The reason you need to declare properties again in an indicator that inherits one of your classes is so the NSWrappers generator finds the property.