On Thursday 17 July 2014 21:31:31 André Pönitz wrote:
PS: Random side-track question: How comparable are values of type 'int'
and 'QUrl' if one applies 'common sense'? I even accept answer related
to non-0 int values only.
The trouble with common sense is that it is not very common in any
On Jul 16, 2014, at 1:45 PM, Poenitz Andre andre.poen...@digia.com wrote:
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
[...]
What is wrong with string - int or bytearray - int?
At the very least, _implicit_ conversions should not lose data,
i.e. a A a1; B b = a1; A a2 = b; round trip
On Thursday 17 of July 2014 10:51:03 you wrote:
QVariant::operator== is not symmetric
QDateTime dateTime = QDateTime::currentDateTime();
QTime time = dateTime.time();
qDebug() (QVariant(dateTime) == QVariant(time));
qDebug() (QVariant(time) == QVariant(dateTime));
--
On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
On Thursday 17 of July 2014 10:51:03 you wrote:
QVariant::operator== is not symmetric
QDateTime dateTime = QDateTime::currentDateTime();
QTime time = dateTime.time();
qDebug() (QVariant(dateTime) ==
On Thursday 17 July 2014 13:33:49 Daniel Teske wrote:
A equals operator that is not symetric is broken. Such a class cannot be
reliably used in std nor qt containers. Or do you know which way around,
QList::contains uses the equals operation?
Note that none of the class which have a member
On Thursday 17 of July 2014 13:33:49 Daniel Teske wrote:
On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
On Thursday 17 of July 2014 10:51:03 you wrote:
QVariant::operator== is not symmetric
QDateTime dateTime = QDateTime::currentDateTime();
QTime time =
On Jul 17, 2014, at 2:38 PM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:
On Thursday 17 of July 2014 13:33:49 Daniel Teske wrote:
On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
On Thursday 17 of July 2014 10:51:03 you wrote:
QVariant::operator== is not symmetric
On Jul 17, 2014, at 1:28 PM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:
On Thursday 17 of July 2014 10:51:03 you wrote:
QVariant::operator== is not symmetric
QDateTime dateTime = QDateTime::currentDateTime();
QTime time = dateTime.time();
qDebug() (QVariant(dateTime) ==
On Thu, Jul 17, 2014 at 02:36:22PM +0200, Olivier Goffart wrote:
On Thursday 17 July 2014 13:33:49 Daniel Teske wrote:
A equals operator that is not symetric is broken. Such a class cannot be
reliably used in std nor qt containers. Or do you know which way around,
QList::contains uses the
On Thu, Jul 17, 2014 at 02:38:40PM +0200, Jędrzej Nowacki wrote:
On Thursday 17 of July 2014 13:33:49 Daniel Teske wrote:
On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
On Thursday 17 of July 2014 10:51:03 you wrote:
QVariant::operator== is not symmetric
QDateTime
On Jul 15, 2014, at 7:36 PM, Olivier Goffart oliv...@woboq.com wrote:
On Tuesday 15 July 2014 10:38:52 Poenitz Andre wrote:
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a
On Tuesday 15 of July 2014 11:59:03 Olivier Goffart wrote:
1.3 Should we try to support a user's type conversions out of the
box?
Currently a user needs to manually register a conversion function
so Qt can know it and use it. For certain types we can do much better,
On Tuesday 15 of July 2014 10:38:52 Poenitz Andre wrote:
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a
behavior
change, as this code:
if
Olivier Goffart wrote:
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth
changing it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an nice to have
base?
On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote:
I wholeheartedly disagree. Most of my QVariant uses are there because
the Qt API requires me to use it, and I sometimes use it voluntarily for
type-agnostic storage or transport of things. But in those cases I never
want to extract
On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
[...]
When one use QVariant, it is because we want to enjoy dynamic typing and
nice conversions.
I don’t think we have a single place in Qt Creator where we want automatic
conversions when using QVariant. A search for
On Wednesday 16 of July 2014 08:41:07 Poenitz Andre wrote:
Olivier Goffart wrote:
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth
changing it.
Why?
On one hand you promise binary compatibility. On the other hand
Olivier Goffart:
Poenitz Andre wrote:
I wholeheartedly disagree. Most of my QVariant uses are there because
the Qt API requires me to use it, and I sometimes use it voluntarily for
type-agnostic storage or transport of things. But in those cases I never
want to extract anything else from
On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote:
Olivier Goffart wrote:
It's always a dilemma. We have to look at how likely we are to break
applications and I don't think adding a conversion is likely to cause
breakages.
Type safety is a safety net that catches errors very early
Jędrzej Nowacki wrote:
Eike wrote:
[...]
We use common sense on a case by case basic.
Either there is no “common sense” common to me, or this rule has failed in
the past already ;)
bool - string ?
bytearray - int/long/double ?
keysequence - int ?
string - bool ?
string -
On Jul 16, 2014, at 11:28 AM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:
On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
[...]
When one use QVariant, it is because we want to enjoy dynamic typing and
nice conversions.
I don’t think we have a single place in Qt Creator
On Jul 16, 2014, at 11:58 AM, Konrad Rosenbaum kon...@silmor.de wrote:
On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote:
Olivier Goffart wrote:
It's always a dilemma. We have to look at how likely we are to break
applications and I don't think adding a conversion is likely to cause
On Wednesday 16 July 2014 10:06:52 Poenitz Andre wrote:
Jędrzej Nowacki wrote:
Eike wrote:
[...]
We use common sense on a case by case basic.
Either there is no “common sense” common to me, or this rule has failed
in
the past already ;)
bool - string ?
bytearray -
On Wednesday 16 of July 2014 12:51:36 Olivier Goffart wrote:
On Wednesday 16 July 2014 10:06:52 Poenitz Andre wrote:
Jędrzej Nowacki wrote:
Eike wrote:
[...]
We use common sense on a case by case basic.
Either there is no “common sense” common to me, or this rule has
On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
I don’t think we have a single place in Qt Creator where we want automatic
conversions when using QVariant. A search for QVariant(Map) returns 5400
hits. In the map case, we usually expect the one retrieving the value for a
key to know
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
[...]
What is wrong with string - int or bytearray - int?
At the very least, _implicit_ conversions should not lose data,
i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield
a1 == a2.
If I am ready to give up
Anyway. To summarize my position in the original context: QVariant
is as it is. It is convenient at times, and it is already too convenient
at times. Easy type conversion is a different use case than Type
agnostic storage. QVariant does a bit of both, only the second one
has ever been useful
Hi
In the qml designer we are using comparisons of variants quite extensive and
run in smaller problems like wrong conversions. E.g. color is broken because
the alpha value is not used in the comparison. We would like to extent existing
comparisons too because we get the variants from
On Jul 16, 2014, at 1:30 PM, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:
On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
I don’t think we have a single place in Qt Creator where we want automatic
conversions when using QVariant. A search for QVariant(Map) returns 5400
hits. In
On Wednesday 16 July 2014 15:01:53 Ziller Eike wrote:
No idea what happens in animations, but I’d suppose that any conversions
there would be accidentally.
QPropertyAnimation is based on modifying QVariants, isn't it?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect -
On Jul 16, 2014, at 5:04 PM, Thiago Macieira thiago.macie...@intel.com wrote:
On Wednesday 16 July 2014 15:01:53 Ziller Eike wrote:
No idea what happens in animations, but I’d suppose that any conversions
there would be accidentally.
QPropertyAnimation is based on modifying QVariants,
On Tuesday 15 July 2014 08:55:29 Jędrzej Nowacki wrote:
Hi,
I would like to discuss type conversions in Qt. As you may know, Qt has
the ability to convert a known type to another known type. This works for
trivial cases like, for example, int to long, but also for more complex
ones like
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom
On Tuesday 15 July 2014 10:38:52 Poenitz Andre wrote:
Olivier Goffart wrote:
Jędrzej Nowacki wrote:
1. Are we allowed to add new conversions?
The question is tricky because adding a new conversion is a
behavior
change, as this code:
if
34 matches
Mail list logo
