Previously, I would just assign all useful traits to all types, no
matter on how they were actually used.
Now it builds all dependnecies and considers them when assigning
traits, which is as precise as we need it.
This is important to us as the `Json` type is just encodable, but
not decodable. Fortunately, we just have to encode it, but in theory
this makes it hard to embed any json in a known structure.
Due to shared global state which was altered, we got wrong results.
This is fixed now, thanks to a deepcopy. Amazing, how altering global
state is always biting you, even though you are convinced it's safe
to do in just this case !
General rule: Just don't do it, no matter what !
Into a complete, global list of schemas, with additional meta-data.
However, it's currently not complete, as $refs are missing.
There is some resemblance to to_rust_type(...), which worries me
slightly
It is a Json object, with a schema as defined elsewhere. It's quite
cool to see this (nearly) working already. However, it will require
us to transitively assign the required markers which is based
on information we don't currently have.
Maybe implementing this could also help to simplify name-clash checks
or make them better at least ?
It was possible for a nested type to be generated with a name that in
fact CLASHED with an existing schema type. What are the odds !
The clash-check added will just verify against clashes with schema
types, which seems to be doing it for now.
At least so it appears.
The implementation doesn't look totally clean to me, as it seems
similar concerns are in different portions of the code, which was
merely tuned to work together.
It could break appart if someone - me - wants to change it sometime
These are arrays or HashMaps, which are nested types too. This is used
to have custom types of standard vectors or hashmaps, which resolve
to NewTypes in Rust.
It seems we do it better than the actual Go implementation, which fails
to detect that scopes are actually having a string member.
However, there still is an issue, as it's as hashmap for us, but just
a member for go ... lets see ...
https://developers.google.com/discovery/v1/reference/apis#resource
shows that we implement it correctly :) !!
This involves disabling the dead-code lint, which is just to ease
debugging, currently there is a lot of dead code as 'hub' is never used.
Soon, this will change, so the lint will be enabled again.
It was possible for writes to happen in nested dicts, causing global
data to change and confuse the system.
Not that I wouldn't be aware of that danger, but apparently I didn't
see the recursiveness of the call tree :).
It seems nearly nothing can be taken for granted ;).
It's best to just run against a big set of APIs and fix issues as they
arise though.
More flexibility means more maintenance, after all.
... it shows that the override I used previously won't work for `admin`.
Therefore we have to keep the actual value, instead of degenrating it.
Makes sense ... it's interesting how much one tends to hard-code things
to work just for a few cases, unless you opt in to see the whole picture
This file is completely generated, and allows us to easily bring in
new versions after each json update.
To make that work, we simple merge all data handed to mako-render,
inside of it. That way, we can put 'api/list' data in any yaml.
That way, we don't have recursive method builders, but instead
flatten the hierarchy. In our case, this is easier and means
less to type. E.g.
`hub.user().message().import(...)` now is
`hub.user().message_import(...)`
In go it would look like this though
`hub.user.messages.import(...)
which is neater.
We will never have that though, as it will initialize a massive amount
of data right on the stack, even though only some of it is ever used
... .
However, this also means we need recursive builders, which is tottally
unsupported for now ... .
This means we have to generalize rbuild generation ... could be easy.
Lets see
That way, we make retrieved tokens independent of the order scopes
were passed in. Additionally, we can pass any scopes, just in case
someone uses one token for multiple APIs.
Let's keep it flexible.
... however, it will become an enumeration, as I don't like people
putting in strings all by themselves. This also means we have to
generate good enums ourselves.
It works for uploads as well as for others.
Next up is to setup the head and authentication. It will be as simple
as calling and handling `GetToken`, even though I think that there
needs to be better support for the scope that is asked for ... .
Now query params are handled completely, including clash check.
Additionally, there is a new result type which encapsulates everything.
It must be typed to the actual result type though, which can be a
request result
Custom property annotations have been very useful, to steer very special
cases.
It's also good that now there is enough infrastructure to deal with
any amount of additional type parameters.
To avoid an additional type parameter, we will use dynamic dispatch
for the delegate.
Having function overrides at some point seems like an excercise better
left for version 1.1 ;)
With a big but ! The most simple thing to do it was to just add
additional type parameters to the respective method.
Now the type cannot be inferred, which means type-hints must be added.
This should be easy enough, but ... has to be done somehow.
