From: "Mårten Nordheim" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [Development] Introducing discussion about QStringFormatter
This discussion's about a proposed 'QStringFormatter' class (for which I put up an early WIP for here: https://codereview.qt-project.org/#/c/192873/ )
QStringFormatter is currently intended as a class to format strings and replace placeholders, like QString::arg does.
But without the issues that QString::arg has. Such as the lack of an end-delimiter (enabling issues such as QString("%2%1").arg(1).arg(1) == "1"), having to parse the string multiple times (if using .arg-chaining).
However, it also adds new features:
- More formatting options, currently QString::arg only has a few options, with QStringFormatter we should initially match the options from QString and then extend the amount of options/features available.
- Instead of only taking formatting options as arguments as in QString::arg, QStringFormatter will support taking formatting options as either in-string formatting or later (exact implementation not yet decided (see notes further down))
- Python: '{:>30}'.format('right aligned')
- C#: String.Format("{0,30}", "right aligned");
- fmt(c++) fmt::format("{:>30}", "right aligned");
- Currently the WIP-version uses '$' as a separator between options and the identifier (i.e. "{1$>30}"), but this may change to match others such as python and fmt.
- New, but familiar syntax. In various languages and libraries the curly braces are used to delimit replacement fields when formatting strings, for example:
- Python: 'Hello, {0}'.format('World')
- C#: String.Format("Hello, {0}", "World");
- fmt(c++): fmt::format("Hello, {0}", "World");
- Note: To print a curly brace they have to be doubled (same as in all of the above) ( "{{", "}}" )
- Named replacement fields. i.e. QStringFormatter("Hello, {name}").arg("name", "World");
- Python: 'Hello, {name}'.format(name='world')
- C#: string name = "World"; $"Hello, {name}"; // uses string interpolation
- fmt(c++): fmt::format("Hello, {name}, fmt::arg("name", "World"));
While this makes it a 'replacement' for QString::arg, we are not going to remove QString::arg (at least not until *much* later.)
1. Why do we [not] want QStringFormatter in the library?
2. If QStringFormatter gets implemented, what are its hard requirements?
3. What are its soft requirements?
And here are some notes I made for myself during the last week:
- In-string formatting options are fine, but can not be the only way to specify formatting (bad for i18n because it becomes part of the text to translate)
- Because of this I could implement a function, i.e. "setFormatting(QString id, QString options)" where 'options' gets parsed the same way as it would if it was in-string
- (would also need an overload which takes 'int' for id)
- could also have a separate function for each formatting option, e.g. "setPadding(id, amount)"
- And/or add an overload of the ::arg functions with an extra argument for formatting, i.e "arg(id, string, format-string)"
- wouldn't work work because of arg(QString, QString, QString)
- 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
- Alternatively: put all BC functionality behind 'arg' and use another function-name for the new formatting style/functionality (e.g. '.format', '.subs')
- pros:
- clear distinction between the functions
- the BC arg-overloads won't cause any issues with new functionality
- No need to disable/enable anything
- cons:
- ??? (can’t think of any at the moment)
- This is probably the better choice of the two..
- ::arg needs to return/be assignable to a QString (can be done using an implicit cast operator or by adding a new (non-explicit) constructor to QString)
- 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
- Mårten Nordheim
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
