[Development] Introducing discussion about QStringFormatter
Mårten Nordheim
marten.nordheim at qt.io
Thu May 18 11:39:36 CEST 2017
On 16.05.2017 19:23, Thiago Macieira wrote:
> 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?
This is enforced for consistency, not because it would cause a problem
for the formatter:
"{{ABC}" vs "{{abs}}"
As well as the fact that it is also done this way in other libraries (I
originally had '\\{' for escaping, but changed it.)
>> - 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")
Hm, hadn't thought that far ahead, thanks. I guess that would be hard to
guess without reading the docs. In this case a constructor parameter is
the better choice for BC.
>> - 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.
I'll have to look into and get back to this
--
Mårten Nordheim
More information about the Development
mailing list