[Development] Introducing discussion about QStringFormatter

[Jason H]

I'm not saying one or the other, python supports both, I'm saying let the developer choose. If positions change, but arg order doesn't, then by all means you must use numbered args. But if the developer doesn't need that then don't make the developer have to maintain it. "Code less. Create more."

I also wonder about the SQL bound parameter interface? That formatting is a mash of :? or :name or something else (":1"?). I think for consistency, that should be able to use whatever the rest of the toolkit does too.

*Apologies to Edward. First reply was not "to-all".

> Sent: Tuesday, May 16, 2017 at 4:12 AM
> From: "Edward Welbourne" <edward.welbourne at qt.io>
> To: "Jason H" <jhihn at gmx.com>, "Mårten Nordheim" <marten.nordheim at qt.io>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Subject: Re: [Development] Introducing discussion about QStringFormatter
>
> Jason H (15 May 2017 23:52):
> > Having worked with Python's format(), I much prefer the alterative {}
> > syntax, where {} defers to the next paramter.
> > '{}{}{}'.format('a', 'b', 'c) == 'abc'
> > Which makes maintence much easier,
> 
> However, it can be problematic for translation; some languages shall
> change word order, which is why it's desirable to provide *some* way for
> the order of substitutions to depart from the order of appearance in the
> format string.
> 
> > partocuclarly when adding a parameter to the beginning. Otherwose your
> > statements get all out of whack:
> > '{3}{1}{2}'.format('b', 'c', 'a') == 'abc'
> 
> where, I take it, the real-world example has lots of text between the
> formatters, 'the {3} brown {1} jumped over the lazy {2}' % ('fox',
> 'dog', 'quick') and renumbering the formatters to 'the {1} brown {2}
> jumped over the lazy {3}' % ('quick', 'fox', 'dog') gets to be tedious
> and susceptible to errors, particularly when the renumbering has to be
> propagated to every translation.  None the less, it's a small price to
> pay for being translatable.
> 
> > I's like the named formatter to take a QVariantMap (JS Object):
> > QVariantMap object;
> > object["name"]="World"; or object= {"name: 'World'} // from QML
> > QStringFormatter("Hello, {name}").arg(object);
> >
> > I'd also like to see QML get fomr formatting love as well.
> 
> The named approach is, indeed, the best of both worlds; translation
> adapts naturally and additions don't require re-indexing.  I suspect C++
> programmers shall find it a bit heavy-weight (needing a hash, of some
> variety, to do simple formatting) but it likely feels much more natural
> at the QML level (just as it does in python).
> 
> 	Eddy.
>