First of, thx for your effort! You did a really great job! And this PR is a good candidate for merging. We might indeed make a typed version of it to be the source for transpiling into all other languages.

It also includes a client for using with https://github.com/franz-see/ccxt-rest (ccxt-rest/ccxt-rest#4) and a basic test suite that allowed me to do some testing on a couple of exchanges

The client itself is ok, however, I would not build it into the lib, instead, I would keep the client a standalone package, and would kink to it from our examples, if you don't mind.

There are a few hacks on json umarshaller methods made as workarounds to type inconsistencies found in several exchange.describe(), maybe it calls for better unification instead (e.g.: https://github.com/ccxt/ccxt/pull/3651/files#diff-629598ca466fdfe7719fd853bcec60e1R45 and https://github.com/ccxt/ccxt/pull/3651/files#diff-629598ca466fdfe7719fd853bcec60e1R73 - basically I encountered both []string and string values on some fields). Some of the exchanges still cannot be instantiated because of other type inconsistencies in their base info (11 out of 129)

I will look carefully into the above inconsistencies and yes, there might a need for more unification in certain cases. We'll figure it out with your help, no worries.

I also remove the emulated value on exchange.has['feature'] dict in the last commit, to avoid having to deal with a 3-value bool, it clearly has repercussions on users so it needs to be taken into consideration. There are alternative approaches but that is the cleanest and simplest one for my purpose

Glad your pointed that out, will consider a better solution, for sure.

One thing that caught my eye after a brief overview is that the naming (the case of letters in particular) differs somewhat from what we have in the base code and in our docs, so, i wanted to ask whether you're ok to stick with the "camelCased" properties within type-structs (first symbol in lowercase) ?

I will review the code more closely asap and will raise questions if any or will suggest edits in code, if i find that necessary. Anyways, we will get through this and will merge, hopefully, soon.

Thanks so much again!

Thanks for the quick feedback, happy to help!

The client itself is ok, however, I would not build it into the lib, instead, I would keep the client a standalone package, and would kink to it from our examples, if you don't mind.

No problem it makes sense, I can submit it to ccxt-rest package. I will also modify the tests so that it doesn't actually test anything but provide a test suite for implementations to test against, it'll be cleaner and doesn't require many changes

One thing that caught my eye after a brief overview is that the naming (the case of letters in particular) differs somewhat from what we have in the base code and in our docs, so, i wanted to ask whether you're ok to stick with the "camelCased" properties within type-structs (first symbol in lowercase) ?

Unfortunately it's not an option in go, first letter's case carry the exported/unexported aspect of any identifier in go : https://golang.org/ref/spec#Exported_identifiers. It would essentially make everything private and only usable inside ccxt/go package

Awesome, I'd love to work on the transpiller, but I need to get better at go first. What is the type system in go? And would we be able to achieve this, without the need to go back and use typescript, since I fear it will make it much more verbose.

@kroitor
Are these all the types ccxt uses to handle data?

int -> safeInteger
float -> safeFloat
string -> safeString
bool -> ?
non-linked-list
linked-list

@frosty00 I'm clueless about the transpiling mechanisms and requirements honestly, but If I can help in any way please shoot

I just went through this page https://code.tutsplus.com/tutorials/deep-dive-into-the-go-type-system--cms-29065 it gives a good overview of the language specs and is a quick read

@rkjdid take a look at https://github.com/ccxt/ccxt/blob/master/transpile.js

It is a pretty extraordinary file that contains all the regex needed to convert to subset of js into python and php. We will have to decide on which types represent which js types then write regexs so that all of the methods of that type are converted into an equivelent statement / method.

For example a simple regex to convert python to js might be.

len\((\w+)\)
$1.length

@frosty

Awesome, I'd love to work on the transpiller, but I need to get better at go first.

Yep, my story is the same )

What is the type system in go?

I think it's very much Java/C++-alike. Though, I'm not 100% sure yet. Looks like a common subset of OOP to me at first glance.

And would we be able to achieve this, without the need to go back and use typescript, since I fear it will make it much more verbose.

Yep, I'm for the path of least resistance as well, ts → ( go | js | py | php | ... )

Are these all the types ccxt uses to handle data?
int -> safeInteger
float -> safeFloat
string -> safeString
bool -> ?

No safeBoolean nor safeBool method yet, but we can add one, of course. Currently, we have been able to get away with safeValue + if (bool) {} else {}.

non-linked-list

Do you mean assoc arrays / dicts / objects ({}) ? No method for them, we can add safeObject or safeDictionary, or safeMap or something else. Otherwise, please clarify )

linked-list

Do you mean flat arrays ([])? No method for them yet, but, again no problem to add safeList.

Second time in this repo – wrong Frosty! :)

@frosty oops, my bad, sorry for disturbing, but you're always welcome here anyways )

@frosty00 we also have a safeInteger2, safeFloat2, etc – those are shorthand wrappers for "either of the two keys in that exact order":

obj = { 'foo': 1, 'bar': 'abc' }
safeFloat (obj, 'foo') // returns 1.0
safeString (obj, 'foo') // returns '1'
safeFloat (obj, 'bar') // returns undefined / None / null, not a float value
safeString2 (obj, 'foo', 'bar', 'abc') // returns '1', 'abc' is the default
safeString2 (obj, 'qux', 'baz', 'abc') // returns 'abc', the default
safeString (obj, 'qux', 'baz') // returns 'baz'