jjttjj / iboga Goto Github PK

They don't keep the download up forever. Now the latest available is 1015.02

maybe this should be taken as an arg?

Example: the algoStrategy property in com.ib.client.Order is a string internally but has setters for both a string and the com.ib.client.Types$AlgoStrategy enum, but that enum contains a subset of the valid algostrategy types and the remaining must be set with the string setter. The getter method .algoStrategy returns the enum, which will have a value of "None" if it is not a valid com.ib.client.Types$AlgoStrategy value. We need to use getAlgoStrategy to get the string version.

Should the getters with a possible getX value as well as a enum getter always return the string getX variant?

Currently qualified keywords are used internally.

They are needed for spec, and I thought I might be able to take advantage of being able to dispatch on a globally unique key with no further context in the same way that spec does for other features besides spec, such as transformation to and from values IB expects/provides, and extension points such as giving a default value to a request parameter, and things such as associating request types with response types and "ending response" types, so that synchronous request can be built upon this data.

Qualified keywords are unwieldy for an enduser to use.

Are they also to unwieldy to an implementer of extension points to use?

Should iboga be built on qualified keywords everywhere, and the unqualifying step be either built on top of this, and/or manually done by the user?

In order for the qualifying step to be opt-in, we would need to change the incoming message handler system so that handlers could be applied in an ordered manner. Or have the unqualifying handler be special, or just an option specified on client creation.

Alternatively, we could go in the opposite directions, and not qualify keywords as often internally, possibly only use them for spec. For example, default request parameters don't need qualified keys. Nested maps can generally replace a hierarchical keyword.

Currently Iboga uses its own "dispatch mechanism", as seen here. Essentially it just keeps a big map in an atom of qualified keywords to maps of functionality implemented for that keyword.

This could also be implemented as multimethods, which has the advantage of being a standard clojure.core feature. However, multimethods feel like they're a bit overkill when they just dispatch on a keyword, and are a bit awkward when we really want to associate data with a keyword and not functionality.

I'm not in love with the naming and terminology of the current setup: set-schema! and "attributes".