[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] printable.lua
- From: Dirk Laurie <dirk.laurie@...>
- Date: Tue, 8 Nov 2011 10:50:12 +0200
2011/11/8 David Manura <email@example.com>:
> 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
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
See previous note: the main aim is the latter — the former is a mere
> (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  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.