Now I just add a 'virtual' resource, which is called 'methods'.
The good thing about this is that it works well standalone, or
in conjunction with actual resources.
Also the system works with it just with minimal changes
Fixes#19
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 :) !!
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
... .
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 ... .
This might mean we need additional type parameters, but I will see how
it's going to work out.
In theory, we could define a new trait for Seek+Read, but this would
mean that we couldn't contain owned streams.
For max flexibility, it's better to have additional type parameters
and use BorrowMut to allow ownership, and borrow.
Previously, it would just show all parts.
It's still not correct though as this isn't necessarily the parts used
in the request value, but only the ones in the response value.
It's as good as it gets though, that's all the information contained
in the json.
This includes descriptions, of course, and generally seems to look
quite neat. For now, we brutally consume all input to own it,
but in future we might be able to put in Borrow to support them all.
Now comes the actual work of setting them up.
Additionally, the docs were decluttered to show comments only
were necessary. Now the code path to getting the hub is as concise as
possible.
Makes everything evaluate faster, and is good enough as well.
Besides, you don't have to think about whitespace too much, keeping
things simpler is usually better
This works with a new `indent` and `unindent` filters respectively.
There are a few things to consider, but I have understood how it works
and can handle it.
There is some overhead just to give me nicer visuals ... might choose
a different route, like annotations.
This includes docs for the library usage.
It's totally great to be able to paste example code right were it
belongs, and also put the same elsewhere to compose more complex docs.
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.
A note like that is now added to all files we generated, commented out
depending on the file type.
Quite neat, except that for filtering, I always have to use blocks.
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.
