Consider opening Order classes about roboquant HOT 9 CLOSED

Will have a look at it. To be honest, orders are not completely flashed out. For example they should expose some more properties at top level to be better usable for margin calculations for open orders.

Are there specific things you are currently missing in the order classes for your strategies ?

from roboquant.

We're building safety orders (something like this https://help.3commas.io/en/articles/3318069-handle-opposite-market-moves-with-safety-orders) and for this we started copying the bracket order. We ended up with a custom order type that handles the incremental moves. The same thing happened when we implemented trailing stop orders, it'd probably been easier to just extend the bracket to handle moving the SL (and sometimes the profit) components. Our idea is to have higher level orders to use in our policies.

Since you mention it, design-wise I thing that Executions should be moved outside the orders, since they're mainly used from the sim broker.

from roboquant.

Interesting background history: originally the execution was outside the order and handled solely by the SimBroker (for same design reasons you mentioned). Problem was that if someone implemented their own order type, they would also need to have to change the logic in the SimBroker. I guess possible a cleaner solution would be to have the two separated, Order and OrderExecution and OrderExecution would only be required if you need to do backtesting. Some more food for thought.

P.S also not big fan currently of the mutable state of an order, it is a bit messy. So if I can come up with some nice design (that is not too difficult to understand for less experienced developers), will see if I refactor that before the 0.9 version.

from roboquant.

+1 for having separate Order and SimOrderExecution hierarchies or interfaces. It'd make things clearer in the order and would allow to have a clean simbroker as iit is now.

Regarding Order mutability (actually, the whole account tree): while it's a little more cumbersome to have everything immutable, it is also way clearer. I've been writing Scala for the last 10 years or so and it's extremely liberating to not to have to think about side effects and changing something that shouldn't be touched in a particular scope. Copying the objects at the beginning of the methods is also not foolproof.

from roboquant.

I agree with the exposed Account being exposed to be just an immutable object. Just to provide quick update on some ongoing prototype (and line of thoughts)

• Orders will become immutable and are just simple "value" objects, so also contain no execute logic anymore.
• SimBroker uses OrderExecutors to implement the execution logic for the different types of orders. This will be all encapsulated in a ExecutionEngine.
• Account should indeed become immutable. SimBroker (and other broker implementations) can keep any mutable account state internal and only expose this immutable Account.
• There is something new called OrderSlip or OrderInfo that will contain both the original order and latest state of that order. It is the broker implementation that that create and maintains this object. Should be immutable since Account will expose this type.

Will soon update the GitHub with a branch called order_new that contains already some of this rework, but still very low quality and a lot of changes still coming in the coming weeks. So don't use this branch for any real work (but feedback is welcome).

from roboquant.

from roboquant.

I would say leave this open until the branch is merged with the main branch.

The returned account is should now be immutable indeed (and there is an InternalAccount used by SImBroker and other Broker to keep their state if they want to).

Regarding serializable, are you using the Kotlin serializing framework or something else?

from roboquant.

from roboquant.

Right now branch is merged, but feel free to open another issue if more specific serialisation requirements exist.

from roboquant.