Public vs Private API is unclear

[glennmoy]

Besides TableGenerator it's not clear which functions are public vs private API.
Empirically, one would think generate is the only public-facing function but it's not documented one way or the other.

[ararslan]

One of the unusual things about this package's API is that the functions one extends to generate rows aren't really intended to be called by the user. For example, you're expected to define a new method for visit!, but realistically there's no situation in which you'd actually call visit!, you only take advantage of the fact that the method you defined allows you to call generate.

[glennmoy]

One of the unusual things about this package's API is that the functions one extends to generate rows aren't really intended to be called by the user. For example, you're expected to define a new method for visit!, but realistically there's no situation in which you'd actually call visit!, you only take advantage of the fact that the method you defined allows you to call generate.

yeah totally understand, and I think for that reason generate should be exported and documented as part of the public API which users call vs the private methods they should extend if they want to support new generator types.

[ararslan]

We may want to consider exporting generate under the name generate_rows in order to differentiate it from generate_tables, which we should also export, and also because generate_rows is strictly more descriptive of what the function actually generates.