Re: [ANN] printable.lua

[Dirk Laurie <dirk.laurie@...>]

2011/11/8 David Manura <dm.lua@math2.org>:
> A couple comments of my own ;)
Thanks, these are really helpful.

> (1) Personally, I like to mention such alternate design options
> in a "DESIGN NOTES" section of the documentation.
I've got a 'warning' section, which says:
   The default custom settings have been chosen to "serialize" the table
   (i.e. to translate it to valid Lua code that will clone it) if that is
   reasonably possible.  Such serialization is not the main aim of the
   module…

But the idea of "DESIGN NOTES" is a good one for the future.  At this
stage it would suggest that more thought has gone into weighing
alternatives than would be justified.

> (2) You might consider splitting this into two modules: one that dumps
> tables to strings and one that adds a `__tostring` metamethod to
> tables.
See previous note: the main aim is the latter — the former is a mere
side effect.

> (3) The module name `printable` is more restrictive than in practice.
> Although you may pass the dumpable table to `print`, you might not
> utilize `print` at all.  It's perfectly valid, for example, to pass
> the dumpable table to `tostring` and store the result string in a
> database without printing it.
My first name [1] for what became this module was "gstring", short for
"generalized string".  It provoked some banter on its name but no
comments on the idea.  So I changed the name.

> (5) LuaInspect tells me the various things:
Thanks for the pointer.  I've just installed the Vim plugin. It's
clearly a great tool.

I agree with all your points, except this:
> passing `ptab` as the first
> argument to `init` which is the unused `dummy` suggests this argument
> might simply be removed.
It's required by the __call metamethod.  But yes, it's neater to pick
up ptab from the argument list, not from the local table.

> (6) It's best to avoid side-effects on module loading.  This includes
> the top-level `io.stderr:write(idea..helphelp)`.  (Moreover, in some
> cases, `io.stderr` might not be open.)
I asked about this in a previous thread.  I want the interactive user
to know how to get to the built-in help without reading the source
code.  Maybe us Lua programmers could agree that a module supplies
`mymod.help()` more often than not.

Thanks
Dirk