With nearly fully randomized examples to show how it can be done.
It's quite nice to see actual calls, using everything required to get
a call. The only thing the user has to manage is to fill in actual
values.
But, it also shows that our builder pattern doesn't work yet due to ...
you guessed it ... lifetime issues :D
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.
Previously, they would take everything as reference and clone
everything unconditionally. Now we do it only as we need to do it,
no extra work incurred.
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.
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.
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.
Previously, they were in an extra, oddly named crate.
Now we just make it a part of our generated codebase.
That way, traits, and common code, shows up as part of the library.
Fair enough.
This also means that the types ar not reusable.
Maybe a mixed-mode can be used if that is desired.
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.
That way, we have a common library to pull in from the main repository,
and a space for testing new code (in a partial implementation).
Next there will be generated object structures.
That way, the makefile doesn't need to know that much anymore, and
gets simpler/less verbose.
\# Also
* Added filters for rust doc string
* fixed .PHONY
Namespaces can exclusively be used during rendering, which is fine if
you remind yourself of the newline rules.
However, I also need some utiltiies that convert input data. These
are now within their own libraries, which can be used from python blocks
like the ordinary python functions they are.
Quite neat.
In future, most of the functionality will be in separate namespaces,
the top-level will just assemble the main library file, usnig the
provided %defs. That way, the main file is kept clean.
It's quite final, and super easy to change and to read.
It seems we want to use namespaces/shared implementations soon to allow
using defs. In our case, we transform the version in a particular way,
which is easy enough, yet I'd like to use it to make the system more
powerful.
That way, we read the data files only once, but produce all the outputs
we need. Together with a powerful makefile, we have a multi-invocation
with proper depedency tracking.
Everything will be regenerated though, even though just a single input
template file changed.
The alternative would be to have one dependency and invocation per
input dependency, but that will read the entire json each time.
Let's see what's faster/more useful during development.
Now we can write mako templates, with a similar feature set as
pyratemp. Except that its syntax is nicer, allows to do everything
and that there is syntax highlight support.
Let's see how it fares
After minor modifications to pyratemp, it certainly does the job.
What it **does NOT** do:
* multiple outputs per template/command invocation
* NICE embedding of code (like GSL can)
It will do the job nonetheless, but mako might be worth a look
