Le mardi 11 août 2015 à 10:10 -0700, Thiago Macieira a écrit :
On Tuesday 11 August 2015 18:45:10 Julien Blanc wrote:
Le mardi 11 août 2015 à 08:46 -0700, Thiago Macieira a écrit :
On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote:
That point is certainly valid, but i would like to
What are the chances that such a change can be accepted ? (i mean, i can
submit such a patch, but that would mean breaking a *lot* of code).
QOptional does not exist yet and for very good reasons.
QVariant is already in use, so I don't think you'd be sending a patch to use
Le vendredi 31 juillet 2015 à 09:01 -0700, Thiago Macieira a écrit :
thiago.macie...@intel.com wrote:
In this particular case, it was reasoned that the API was inconsistent and
broken. So the behaviour was changed intentionally.
TBH, it looks like it's still inconsistent (an empty
On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote:
That point is certainly valid, but i would like to raise the point that
string nullness is a *required* feature for QtSQL (a null QString is
converted to a NULL SQL, whereas a non-null empty QString is converted
That's a misfeature. QtSql
Le mardi 11 août 2015 à 08:46 -0700, Thiago Macieira a écrit :
On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote:
That point is certainly valid, but i would like to raise the point that
string nullness is a *required* feature for QtSQL (a null QString is
converted to a NULL SQL,
On Tuesday 11 August 2015 19:09:22 Allan Sandfeld Jensen wrote:
I would second that. We can argue that the null vs empty is a misfeature we
like to discourage because it is likely to break in some corner-cases, but
until we get rid of it (Qt6), there is no reason to not try to be
consistent,
On Tuesday 11 August 2015, Julien Blanc wrote:
Le mardi 11 août 2015 à 08:46 -0700, Thiago Macieira a écrit :
On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote:
That point is certainly valid, but i would like to raise the point that
string nullness is a *required* feature for QtSQL (a
On Tuesday 11 August 2015 18:45:10 Julien Blanc wrote:
Le mardi 11 août 2015 à 08:46 -0700, Thiago Macieira a écrit :
On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote:
That point is certainly valid, but i would like to raise the point that
string nullness is a *required* feature for
On Friday 31 July 2015 10:30:33 Giuseppe D'Angelo wrote:
On Fri, Jul 31, 2015 at 10:25 AM, Thiago Macieira
thiago.macie...@intel.com wrote:
In this particular case, it was reasoned that the API was inconsistent and
broken. So the behaviour was changed intentionally.
TBH, it looks like
From: development-bounces+jaroslaw.kobus=theqtcompany@qt-project.org
development-bounces+jaroslaw.kobus=theqtcompany@qt-project.org on behalf
of Matthew Woehlke mwoehlke.fl...@gmail.com
Sent: 30 July 2015 18:14
To: development@qt-project.org
Subject: Re: [Development] QString behavior change
* Kobus Jaroslaw jaroslaw.ko...@theqtcompany.com [2015-07-31 07:46:07 +]:
If you say not to differentiate empty and null states, some questions arise:
1) Why we have isNull and isEmpty at the same time?
2) Why their implementations are different?
3) What would be the advice on what to use
Op 31-7-2015 om 09:48 schreef Oswald Buddenhagen:
On Thu, Jul 30, 2015 at 08:37:28AM -0700, Thiago Macieira wrote:
On Thursday 30 July 2015 11:47:16 Olivier Goffart wrote:
On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote:
Hi
The behavior of QString::trimmed has changed from 5.3.2 to
On Thu, Jul 30, 2015 at 08:37:28AM -0700, Thiago Macieira wrote:
On Thursday 30 July 2015 11:47:16 Olivier Goffart wrote:
On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote:
Hi
The behavior of QString::trimmed has changed from 5.3.2 to 5.5.
.trimmed() on an empty string ( )
On Friday 31 July 2015 09:48:08 Oswald Buddenhagen wrote:
well, that recommendation is reasonable in face of the status quo, but
i think we should (and could) do a better job at preserving nullness.
there are only a handful of cases where the choice is arbitrary, and we
can clearly document
On Friday 31 July 2015 09:53:32 André Somers wrote:
If nullness can't be relied on to be retained or non-null strings can
degrade into being a null string, what's the point of having it at all?
There are corner-cases. Like using QString() to indicate no match found.
When you search for empty
On Fri, Jul 31, 2015 at 10:25 AM, Thiago Macieira
thiago.macie...@intel.com wrote:
In this particular case, it was reasoned that the API was inconsistent and
broken. So the behaviour was changed intentionally.
TBH, it looks like it's still inconsistent (an empty string keeps its
storage
On Thursday 30 July 2015 11:47:16 Olivier Goffart wrote:
On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote:
Hi
The behavior of QString::trimmed has changed from 5.3.2 to 5.5.
.trimmed() on an empty string ( ) makes it null
.trimmed() on an empty string () doesn't make it null
Hi
The behavior of QString::trimmed has changed from 5.3.2 to 5.5.
.trimmed() on an empty string ( ) makes it null
.trimmed() on an empty string () doesn't make it null
Is this intended or a bug?
By the way: the output of qDebug is not as expected:
there are additional whitespaces before
On 2015-07-30 03:38, Gerhard Scheikl wrote:
The behavior of QString::trimmed has changed from 5.3.2 to 5.5.
.trimmed() on an empty string ( ) makes it null
.trimmed() on an empty string () doesn't make it null
Is this intended or a bug?
Whether or not it is¹ should not be relevant; QString
On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote:
Hi
The behavior of QString::trimmed has changed from 5.3.2 to 5.5.
.trimmed() on an empty string ( ) makes it null
.trimmed() on an empty string () doesn't make it null
Is this intended or a bug?
This is caused by
20 matches
Mail list logo
