[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] printable.lua
- From: David Manura <dm.lua@...>
- Date: Mon, 7 Nov 2011 23:41:54 -0500
On Mon, Nov 7, 2011 at 3:43 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> ptab = require "printable"
> S=ptab{msg='hello',1,2,{3,4}}
> print(S) --> {1,2,{3,4},msg="hello"}
A couple comments of my own ;)
(1) An alternative to making tables dumpable (by adding __tostring to
them) is to make `print` know how to dump tables:
local pprint = require 'printable' . print
S = {msg='hello',1,2,{3,4}}
pprint(S) --> {1,2,{3,4},msg="hello"}
-- and optionally replace `pprint` with `print` if you wish to always dump
Which is better? It depends. The latter avoids mutating tables and
adding extra `ptab` calls. The former allows you to mark on the
tables themselves whether they get dumped. Personally, I like to
mention such alternate design options in a "DESIGN NOTES" section of
the documentation.
(2) You might consider splitting this into two modules: one that dumps
tables to strings and one that adds a `__tostring` metamethod to
tables. The former has already been explored at length (
http://lua-users.org/wiki/TableSerialization ), and being a bit lazy
I'd prefer not to go through the validation of this table dumping code
again to determine its qualities relative to others if I just want to
do the latter. A user might want to use your table dumping
independent of the `__tostring` stuff, or the user might want to use
some other table dumper with your `__tostring` stuff.
(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.
(4) No need to `pcall(rawget,mt,'__tostring')` since `rawget` won't raise.
(5) LuaInspect tells me the various things: There's an undefined
global `_sep`, `local unpack` and `local load` are unused, there's an
extraneous tab char, `type` is not consistently localized like the
other functions (however, I tend to localize less than I used to and
might remove all the localization), and passing `ptab` as the first
argument to `init` which is the unused `dummy` suggests this argument
might simply be removed.
(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.)