=encoding utf8 =head1 NAME String::Print - printf alternative =head1 SYNOPSIS ### Functional interface use String::Print; # simpelest way use String::Print qw/printi printp/, %config; printi 'age {years}', years => 12; # interpolation of arrays and hashes (serializers) printi 'price-list: {prices}', prices => \@p, _join => "+"; printi 'dump: {c}', c => \%config; # same with positional parameters printp 'age %d", 12; printp 'price-list: %.2f', \@prices; printp 'dump: %s', \%settings; # modifiers printi 'price: {price%.2f}', price => 3.14*VAT*EURO; # [0.91] more complex interpolation names printi 'filename: {c.filename}', c => \%config; printi 'username: {user.name}', user => $user_object; printi 'price: {product.price €}', product => $db->product(3); ### Object Oriented interface use String::Print 'oo'; # import nothing my $f = String::Print->new(%config); $f->printi('age {years}', years => 12); $f->printp('age %d', 12); ### via Log::Report's __* functions (optional translation) use Log::Report; # or Log::Report::Optional print __x"age {years}", years => 12; ### via Log::Report::Template (Template Toolkit extension) [% SET name = 'John Doe' %] [% loc("Dear {name},") %] # includes translation =head1 DESCRIPTION This module inserts values into (format) strings. It provides C and C alternatives via both an object oriented and a functional interface. Read in the L chapter below, why this module provides a better alternative for C. Also, some extended B can be found down there. Take a look at them first, when you start using this module! =head1 METHODS =head2 The Object Oriented interface See functions L, L, L, and L: you can also call them as method. use String::Print 'oo'; my $f = String::Print->new(%config); $f->printi($format, @params); # exactly the same functionality: use String::Print 'printi', %config; printi $format, @params; The Object Oriented interface wins when you need the same configuration in multiple source files, or when you need different configurations within one program. In these cases, the hassle of explicitly using the object has some benefits. =head3 Constructors =over 4 =item String::Print-EB(%options) -Option --Default encode_for undef missing_key modifiers [ qr/^%\S+/ = \&format_printf]> serializers =over 2 =item encode_for => HASH|'HTML' [0.91] The format string and the inserted values will get encoded according to some syntax rules. For instance, C of HTML::Entities when you specify the predefined string C. See L. =item missing_key => CODE [0.91] During interpolation, it may be discovered that a key is missing from the parameter list. In that case, a warning is produced and C inserted. May can overrule that behavior. =item modifiers => ARRAY Add one or more modifier handlers to power of the formatter. They will get preference over the predefined modifiers, but lower than the modifiers passed to C itself. =item serializers => HASH|ARRAY How to serialize data elements. =back example: my $f = String::Print->new ( modifiers => [ EUR => sub {sprintf "%5.2f e", $_[0]} ] , serializers => [ UNDEF => sub {'-'} ] , encode_for => 'HTML' ); $f->printi("price: {p EUR}", p => 3.1415); # price: ␣␣3.14 e $f->printi("count: {c}", c => undef); # count: - =back =head3 Attributes =over 4 =item $obj-EB(PAIRS) The PAIRS are a combination of an selector and a CODE which processes the value when the modifier matches. The selector is a string or (preferred) a regular expression. Later modifiers with the same name overrule earlier definitions. You may also specify an ARRAY of modifiers per C. See section L about the details. =item $obj-EB(HASH|undef|($predefined, %overrule)) [0.91] Enable/define the output encoding. Read section L about the details. =back =head3 Printing The following are provided as method and as function. You find their explanation further down on this page. $obj->B([$fh], $format, PAIRS|HASH); $obj->B([$fh], $format, PAIRS|HASH); $obj->B($format, PAIRS|HASH); $obj->B($format, LIST, PAIRS); =head1 FUNCTIONS The functional interface creates a hidden object. You may import any of these functions explicitly, or all together by not specifying the names. B<. Example> use String::Print; # all use String::Print 'sprinti'; # only sprinti use String::Print 'printi' # only printi , modifiers => [ EUR => sub {sprintf "%5.2f e", $_[0]} ] , serializers => [ UNDEF => sub {'-'} ]; printi "price: {p EUR}", p => 3.1415; # price: ␣␣3.14 e printi "count: {c}", c => undef; # count: - =over 4 =item B( [$fh], $format, PAIRS|HASH ) Calls L to fill the data in PAIRS or HASH in $format, and then sends it to the $fh (by default the selected file) open my $fh, '>', $file; printi $fh, ... printi \*STDERR, ... =item B( [$fh], $format, PAIRS|HASH ) Calls L to fill the data in PAIRS or HASH in $format, and then sends it to the $fh (by default the selected file) =item B($format, PAIRS|HASH|OBJECT) The $format refers to some string, maybe the result of a translation. The PAIRS (which may be passed as LIST, HASH, or blessed HASH) contains a mixture of special and normal variables to be filled in. The names of the special variables (the options) start with an underscore (C<_>). -Option --Default _append undef _count undef _join ', ' _prepend undef =over 2 =item _append => STRING|OBJECT Text as STRING appended after $format, without interpolation. =item _count => INTEGER Result of the translation process: when Log::Report subroutine __xn is are used for count-sensitive translation. Those function may add more specials to the parameter list. =item _join => STRING Which STRING to use when an ARRAY is being filled-in as parameter. =item _prepend => STRING|OBJECT Text as STRING prepended before $format, without interpolation. This may also be an OBJECT which gets stringified, but variables not filled-in. =back =item B($format, LIST, PAIRS) Where L uses named parameters --especially useful when the strings need translation-- this function stays close to the standard C. All features of POSIX formats are supported. This should say enough: you can use C<%3$0#5.*d>, if you like. It may be useful to know that the positional $format is rewritten and then fed into L. B with the length of the LIST: superfluous parameter PAIRS are passed along to C, and should only contain "specials": parameter names which start with '_'. example: of the rewrite # positional parameters my $x = sprintp "dumpfiles: %s\n", \@dumpfiles , _join => ':'; # is rewritten into, and then processed as my $x = sprinti "dumpfiles: {_1}\n" , _1 => \@dumpfiles, _join => ':'; =back =head1 DETAILS =head2 Why use C, not C? The C function is provided by Perl's CORE; you do not need to install any module to use it. Why would you use consider using this module? =over 4 =item translating C uses positional parameters, where L uses names to refer to the values to be filled-in. Especially in a set-up with translations, where the format strings get extracted into PO-files, it is much clearer to use names. This is also a disadvantage of L =item pluggable serializers C supports serialization for specific data-types: how to interpolate C, HASHes, etc. =item pluggable modifiers Especially useful in context of translations, the FORMAT string may contain (language specific) helpers to insert the values correctly. =item correct use of utf8 Sized string formatting in C is broken: it takes your string as bytes, not Perl strings (which may be utf8). In unicode, one "character" may use many bytes. Also, some characters are displayed double wide, for instance in Chinese. The L implementation will use Unicode::GCString for correct behavior. =item automatic output encoding (for HTML) You can globally declare that all produced strings must be encoded in a certain format, for instance that HTML entities should be encoded. =back =head2 Four components To fill-in a FORMAT, four clearly separated components play a role: =over 4 =item 1. modifiers How to change the provided values, for instance to hide locale differences. =item 2. serializer How to represent (the modified) the values correctly, for instance C and ARRAYs. =item 3. conversion The standard UNIX format rules, like C<%d>. One conversion rule has been added 'S', which provides unicode correct behavior. =item 4. encoding Prepare the output for a certain syntax, like HTML. =back Simplified: # sprinti() replaces "{$key$modifiers$conversion}" by $encode->($format->($serializer->($modifiers->($args{$key})))) # sprintp() replaces "%pos{$modifiers}$conversion" by $encode->($format->($serializer->($modifiers->($arg[$pos])))) Example: #XXX Your manual-page reader may not support the unicode used #XXX in the examples below. printi "price: {price € %-10s}", price => $cost; printi "price: {price € %-10s}", { price => $cost }; printp "price: %-10{€}s", $cost; $value = $cost (in €) $modifier = convert € to local currency £ $serializer = show float as string $format = column width %-10s $encode = £ into £ # when encodingFor('HTML') =head2 Interpolation: keys A key is a bareword (like a variable name) or a list of barewords separated by dots (no blanks!) B use explanatory key names, to help the translation process once you need that (in the future). =head3 Simple keys A simple key directly refers to a named parameter of the function or method: printi "Username: {name}", name => 'John'; You may also pass them as HASH or CODE: printi "Username: {name}", { name => 'John' }; printi "Username: {name}", name => sub { 'John' }; printi "Username: {name}", { name => sub { 'John' } }; printi "Username: {name}", name => sub { sub {'John'} }; The smartness of pre-processing CODE is part of serialization. =head3 Complex keys [0.91] In the previous section, we kept our addressing it simple: let's change that now. Two alternatives for the same: my $user = { name => 'John' }; printi "Username: {name}", name => $user->{name}; # simple key printi "Username: {user.name}", user => $user; # complex key The way these complex keys work, is close to the flexibility of template toolkit: the only thing you cannot do, is passing parameters to called CODE. You can pass a parameter name as HASH, which contains values. This may even be nested into multiple levels. You may also pass objects, class (package names), and code references. In above case of C, when C is a HASH it will take the value which belongs to the key C. When C is a CODE, it will run code to get a value. When C is an object, the method C is called to get a value back. When C is a class name, the C refers to an instance method on that class. More examples which do work: # when name is a column in the database query result printi "Username: {user.name}", user => $sth->fetchrow_hashref; # call a sub which does the database query, returning a HASH printi "Username: {user.name}", user => sub { $db->getUser('John') }; # using an instance method (object) { package User; sub new { bless { myname => $_[1] }, $_[0] } sub name { $_[0]->{myname} } } my $user = User->new('John'); printi "Username: {user.name}", user => $user; # using a class method sub User::count { 42 } printi "Username: {user.count}", user => 'User'; # nesting, mixing printi "Complain to {product.factory.address}", product => $p; # mixed, here CODE, HASH, and Object printi "Username: {document.author.name}", document => sub { return +{ author => User->new('John') } }; Limitation: you cannot pass arguments to CODE calls. =head2 Interpolation: Serialization The 'interpolation' functions have named VARIABLES to be filled-in, but also additional OPTIONS. To distinguish between the OPTIONS and VARIABLES (both a list of key-value pairs), the keys of the OPTIONS start with an underscore C<_>. As result of this, please avoid the use of keys which start with an underscore in variable names. On the other hand, you are allowed to interpolate OPTION values in your strings. There is no way of checking beforehand whether you have provided all values to be interpolated in the translated string. When you refer to value which is missing, it will be interpreted as C. =over 4 =item strings Simple scalar values are interpolated "as is" =item CODE When a value is passed as CODE reference, that function will get called to return the value to be filled in. For interpolating, the following rules apply: =item SCALAR Takes the value where the scalar reference points to. =item ARRAY All members will be interpolated with C<,␣> between the elements. Alternatively (maybe nicer), you can pass an interpolation parameter via the C<_join> OPTION. printi "matching files: {files}", files => \@files, _join => ', ' =item HASH By default, HASHes are interpolated with sorted keys, $key => $value, $key2 => $value2, ... There is no quoting on the keys or values (yet). Usually, this will produce an ugly result anyway. =item Objects With the C parameter, you can overrule the interpolation of above defaults, but also add rules for your own objects. By default, objects get stringified. serialization => [ $myclass => \&name_in_reverse ] sub name_in_reverse($$$) { my ($formatter, $object, $args) = @_; # the $args are all parameters to be filled-in scalar reverse $object->name; } =back =head2 Interpolation: Modifiers Modifiers are used to change the value to be inserted, before the characters get interpolated in the line. This is a powerful simplification. Let's discuss this with an example. In traditional (gnu) gettext, you would write: printf(gettext("approx pi: %.6f\n"), PI); to get PI printed with six digits in the fragment. Locale::TextDomain has two ways to achieve that: printf __"approx pi: %.6f\n", PI; print __x"approx pi: {approx}\n", approx => sprintf("%.6f", PI); The first does not respect the wish to be able to reorder the arguments during translation (although there are ways to work around that) The second version is quite long. The string to be translated differs between the two examples. With C, above syntaxes do work as well, but you can also do: # with optional translations print __x"approx pi: {pi%.6f}\n", pi => PI; The base for C<__x()> is the L provided by this module. Internally, it will call C to fill-in parameters: printi "approx pi: {pi%.6f}\n", pi => PI; Another example: printi "{perms} {links%2d} {user%-8s} {size%10d} {fn}\n", perms => '-rw-r--r--', links => 7, user => 'me', size => 12345, fn => $filename; An additional advantage (when you use translation) is the fact that not all languages produce comparable length strings. Now, the translators can change the format, such that the layout of tables is optimal for their language. Above example in L syntax, shorter but less maintainable: printp "%s %2d %-8s 10d %s\n", '-rw-r--r--', 7, 'me', 12345, $filename; =head2 Interpolation: default modifiers =head3 Default modifier: POSIX format As shown in the examples above, you can specify a format. This can, for instance, help you with rounding or columns: printp "π = {pi%.3f}", pi => 3.1415; printp "weight is {kilogram%d}", kilogram => 127*OUNCE_PER_KILO; printp "{filename%-20.20s}\n", filename => $fn; =head4 - improvements on POSIX format The POSIX C does not handle unicode strings. Perl does understand that the 's' modifier may need to insert utf8 so does not count bytes but characters. C does not use characters but "grapheme clusters" via Unicode::GCString. Now, also composed characters do work correctly. Additionally, you can use the B to count in columns. In fixed-width fonts, graphemes can have width 0, 1 or 2. For instance, Chinese characters have width 2. When printing in fixed-width, this 'S' is probably the better choice over 's'. When the field does not specify its width, then there is no performance penalty for using 'S'. # name right aligned, commas on same position, always printp "name: {name%20S},\n", name => $some_chinese; =head3 Default modifier: BYTES [0.91] Too often, you have to translate a (file) size into humanly readible format. The C modifier simplifies this a lot: printp "{size BYTES} {fn}\n", fn => $fn, size => -s $fn; The output will always be 6 characters. Examples are "999 B", "1.2 kB", and " 27 MB". =head3 Default modifiers: YEAR, DATE, TIME, DT, and DT() [0.91] A set of modifiers help displaying dates and times. They are a little flexible in values they accept, but do not expect miracles: when it get harder, you will need to process it yourself. The actual treatment of a time value depends on the value: three different situations: =over 4 =item 1. numeric A pure numeric value is considered "seconds since epoch", unless it is smaller than 21000000, in which case it is taken as date without separators. =item 2. date format without time-zone The same formats are understood as in the next option, but without time-zone information. The date is processed as text as if in the local time zone, and the output in the local time-zone. =item 3. date format with time-zone By far not all possible date formats are supported, just a few common versions, like 2017-06-27 10:04:15 +02:00 2017-06-27 17:34:28.571491+02 # psql timestamp with zone 20170627100415+2 2017-06-27T10:04:15Z # iso 8601 20170627 # only for YEAR and DATE 2017-6-1 # only for YEAR and DATE 12:34 # only for TIME The meaning of 05-04-2017 is unclear, so not supported. Milliseconds get ignored. When the provided value has a timezone indication, it will get converted into the local timezone of the observer. =back The output of C is in format 'YYYY', for C it will always be 'YYYY-MM-DD', where C