We assure to know about it, instead of writing nonsense about that
'methods' resources which does not actually exist.
I am relatively sure to have found all the spots.
Fixes#22
These 'methods' have no resources, and need slightly special handling.
This version at least makes the generator work, even though
it produces duplicates.
However, as it is so ugly, I'd rather consider to change it
substantially ... this feature should just come naturally.
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.
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 :) !!
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 :).
What's missing is docs, which will see some work now.
I guess it will be best to hide all the prelude from the user, to allow
him to focus on what's important here.
Now we will generate proper resoure methods builder calls to instaniate
the more or less valid method builders.
However, it doesn't compile yet, and the 'to_parts()' method on
resources is still missing.
Including documentation at least on the method builder part. The
great thing is that fully working examples are now included on
every type !
Now more involved part starts ... namely setting up the individual call
method signatures.
Everything we have, feature wise, is now documented in a first version
at least.
We shall keep this uptodate with what we are implementing, which also
helps figuring out a good api.
However, they are not listed as traits of the youtube api. What we
really want is to list common implementation types as part of ourselves.
This doesn't work though as long as we don't have the common impl
as part of our sources.
Now a context is passed to utility functions, which contains the state
these may be interested in. This keeps it clean from global state.
With the lookup tables, it is possible to figure out relations between
types and document them accordingly.
