IOrder objects and SetXXX() methods for NT7
Hello and happy new year to you all and those close to you.
My little experience in NT6.5 was that NT script API had an 'All or Nothing' design philosophy to it. What I mean for instance is the 'SetXXX()' methods did all the orders handling (oco, etc.) but returned void and gave you no information on any orders objects. The 'EnterXXX()' methods on the other hand, gave orders objects info but the developer had to take care of order handling completely (which is fine under certain circumstances).
But no middle ground between the two, just like in RealtimeErrorHandling (take no action or kill all).
I am assuming that 'internally' (the implementation of the API), the 'SetXXX' and 'EnterXXX()' methods are manipulating 'IOrder' objects for orders (an order is an order regardless of who (which method) submits, cancels or modifies it).
You would increase the 'Maintainability' (therefore, reduce TimeToDelivery, costs (support, upgrade), etc), 'Flexibility' (therefore easy to upgrade, great for developers and users) and all the other OO-related 'ity', by simply exposing the 'IOrder' object for the 'SetXXX' methods.
Not only will it make our life easier, it will increase all of the above, which I presume should be a welcome for you, as the cost benefits far outweight the amount of efforts involved initially.
What's the technical (architectural) and financial argument of not doing it? Other than design constraints, which if it exist, will need looking into anyway.
We all want to see NT elevated to a point where we don't need any other platform (well, I do), and we can then only concentrate on tapping into our creative self or talents to try and make some sort of living in this business.
Yours truly,
Obi
My little experience in NT6.5 was that NT script API had an 'All or Nothing' design philosophy to it. What I mean for instance is the 'SetXXX()' methods did all the orders handling (oco, etc.) but returned void and gave you no information on any orders objects. The 'EnterXXX()' methods on the other hand, gave orders objects info but the developer had to take care of order handling completely (which is fine under certain circumstances).
But no middle ground between the two, just like in RealtimeErrorHandling (take no action or kill all).
I am assuming that 'internally' (the implementation of the API), the 'SetXXX' and 'EnterXXX()' methods are manipulating 'IOrder' objects for orders (an order is an order regardless of who (which method) submits, cancels or modifies it).
You would increase the 'Maintainability' (therefore, reduce TimeToDelivery, costs (support, upgrade), etc), 'Flexibility' (therefore easy to upgrade, great for developers and users) and all the other OO-related 'ity', by simply exposing the 'IOrder' object for the 'SetXXX' methods.
Not only will it make our life easier, it will increase all of the above, which I presume should be a welcome for you, as the cost benefits far outweight the amount of efforts involved initially.
What's the technical (architectural) and financial argument of not doing it? Other than design constraints, which if it exist, will need looking into anyway.
We all want to see NT elevated to a point where we don't need any other platform (well, I do), and we can then only concentrate on tapping into our creative self or talents to try and make some sort of living in this business.
Yours truly,
Obi
Comment