[Development] Introducing discussion about QStringFormatter

Thiago Macieira thiago.macieira at intel.com
Tue May 16 19:23:42 CEST 2017

On segunda-feira, 15 de maio de 2017 05:49:19 PDT MÃ¥rten Nordheim wrote:
>                - Note: To print a curly brace they have to be doubled (same
>                as in all of the above) ( "{{", "}}" )

Why do we need a double closing curly brace? This is not a valid sequence:

	"Closing Brace: }"

Or would the formatter complain if it found that?

> - Backwards compatibility with QString::arg
>                 - Since users would have to make source changes to start
>                 using QStringFormatter anyway I propose putting this
>                 BC-functionality behind a constructor-argument.
>                                - This should also disable parsing
>                                replacement fields with the '{...}'-syntax
>                                                - Would avoid forcing them to
>                                                change the string in case
>                                                they already have
>                                                curly-braces in any strings

I think it's a good idea to choose one or the other, but not both. That allows 
us to avoid having multiply-escaped tokens or anything weird.

>                                 - Alternatively: put all BC functionality
>                                 behind 'arg' and use another function-name
>                                 for the new formatting style/functionality
>                                 (e.g. '.format', '.subs')

The choice of whether to use a constructor or a differently-named function 
will depend on the design choice for your API. So it's up to you. 

Please consider, in terms of Qt API design (ease of use, surprise factor, 
etc.) just what the following should do:

	QStringFormatter("%1 is {1}").arg("foo").subs("bar")

> - i18n could be in a separate class/child-class
>                 - but it should be kept in mind during the design and
>                 implementation of this class to make i18n easier to
>                 implement

No, the MAIN purpose of the formatter is i18n. Therefore, this needs to be in 
the base class and designed from the get-go.

Formatted output to files is a secondary goal (we already have QTextStream). 
Formatted output to the console is a tertiary goal, or even a non-goal.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list