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 se
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
> > > >
> > >
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
On Jul 17, 2014, at 3:14 PM, Ziller Eike wrote:
>
> On Jul 17, 2014, at 1:28 PM, 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.
On Jul 17, 2014, at 1:28 PM, 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) == QVariant(t
On Jul 17, 2014, at 2:38 PM, 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 dateTi
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();
> > >
> > >
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 o
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(
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(dateTim
On Jul 16, 2014, at 1:45 PM, Poenitz Andre 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 idea
On Jul 16, 2014, at 5:04 PM, Thiago Macieira 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, isn't it?
True, but I’
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 1:30 PM, Jędrzej Nowacki 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 the map case, we us
From: development-bounces+marco.bubke=digia@qt-project.org
[development-bounces+marco.bubke=digia@qt-project.org] on behalf of Jędrzej
Nowacki [jedrzej.nowa...@digia.com]
Sent: Tuesday, July 15, 2014 8:55 AM
To: development@qt-project.org
Subject: [Development] Converting types in Qt
Hi,
> 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 bee
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 g
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 kno
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
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
On Jul 16, 2014, at 11:58 AM, Konrad Rosenbaum 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
>>> breakag
On Jul 16, 2014, at 11:28 AM, Jędrzej Nowacki 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 where we want
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 ->
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 ver
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
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 compatibil
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 QV
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 a
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
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:
> > >
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 Jul 15, 2014, at 7:36 PM, Olivier Goffart 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
beh
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:
> > >
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
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
>
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 "QByteArray" to "QString" or "CustomType" to "OtherCust
36 matches
Mail list logo
