[Development] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray
Thiago Macieira
thiago.macieira at intel.com
Thu Jul 2 02:48:49 CEST 2020
On Wednesday, 1 July 2020 15:29:33 PDT Tor Arne Vestbø wrote:
> Hi,
>
> I can sympathize with the reporter that this is a quite serious regression
> from the user’s point of view, but I also see your point about the new
> behavior not being lossy.
> Would it be an alternative to add an argument to QJsonValue::fromVariant
> e.g. that defaults to the old, unsurprising behavior, but allows opting in
> to the safer approach?
That can't be done in 5.15, since we can't add a new function so it can take
an argument. We may relax the rule about forwards-and-backwards compatibility
later for 5.15 like we did for 4.8, but that hasn't happened yet.
Either way, it would need to be the inverse: opt in to the new behaviour. If
we're going to require users to adapt anyway, then we can ask them to fix
their QVariants in the first place.
> I assume people who put “true” binary data into their QByteArrays and
> convert that to JSON would have pre-base64-encoded it manually already, to
> avoid the data loss, so this is a surprising change for those that just use
> it as a poor man’s string.
Agreed, anyone who needed to send binaries in the past would have encoded
somehow (base16, base64 or base64url), but they might have also already moved
it to QString because that's what's documented. If they haven't -- and
QByteArray::toBase64 returns QByteArray -- then we get double encoding, which
is wore.
In a green field scenario, the new behaviour is quite useful. You don't need
to pre-encode, the converter will do it for you.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Development
mailing list