Re: [Interest] QVariant compare operator

2020-04-21 Thread Matthew Woehlke 

On 20/04/2020 12.21, André Pönitz wrote:

On Mon, Apr 20, 2020 at 10:04:38AM -0400, Matthew Woehlke wrote:

On 19/04/2020 08.23, André Pönitz wrote:

QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().

If wanted, this can be refined to make e.g. all integral types comparable.


No:

   int{5} <=> JsonObject{...} => lesser
   int{5} <=> long{3} => greater
   long{3} <=> JsonObject{...} => greater

...oops.


"make comparable" means lumping them into a common "type", say
"@integral", with values covering the union set of the values
of the original type.


...and now your rule for heterogeneous comparisons ***isn't*** 
'according to the type name'. It's 'according to the type name, *except* 
'. Yuck.



You'd have to make all integral types sort before (or after) all other
types, but then you're back to not having a reliable ordering by type name.


No.


Really? Please explain how this is *not* the case.

--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Florian Bruhin 
On Mon, Apr 20, 2020 at 09:50:06AM -0600, Thiago Macieira wrote:
> On Monday, 20 April 2020 03:28:48 MDT Florian Bruhin wrote:
> > FWIW that's the choice Python had taken with Python 2 (ordering different
> > types by their type name). It was widely regarded as a bad decision and
> > replaced by a TypeError exception in Python 3.
> 
> Interesting. Do you have more information on why it is regarded a bad 
> decision? A PEP, hopefully?

I have to admit my "widely regarded as" was perhaps a bit too anecdotal.

It doesn't look like a PEP exists for this, which seems quite surprising. There
was some discussion via email, but it's quite a mess to read, unfortunately:

https://mail.python.org/pipermail/python-dev/2004-June/thread.html
(the "Comparing heterogeneous types" threads)

https://mail.python.org/archives/search?q=Comparing+heterogeneous+types=1=python-dev%40python.org=date-asc
(same content, more modern archive webinterface)

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread André Pönitz 
On Mon, Apr 20, 2020 at 10:04:38AM -0400, Matthew Woehlke wrote:
> On 19/04/2020 08.23, André Pönitz wrote:
> > QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
> > TypeB based e.g. on alphabetical order of their .typeName().
> > 
> > If wanted, this can be refined to make e.g. all integral types comparable.
> 
> No:
> 
>   int{5} <=> JsonObject{...} => lesser
>   int{5} <=> long{3} => greater
>   long{3} <=> JsonObject{...} => greater
> 
> ...oops.

"make comparable" means lumping them into a common "type", say
"@integral", with values covering the union set of the values
of the original type.

   int{5} == "@integral"{5} <=> JsonObject{...} => lesser
   int{5} == "@integral"{5} <=> "@integral{3}" == long{3} => greater
   long{3} == "@integral"{3} <=> JsonObject{...} =>  lesser! // not greater

> You'd have to make all integral types sort before (or after) all other
> types, but then you're back to not having a reliable ordering by type name.

No.

> It makes *much* more sense that some comparisons just come back
> "incomparable".

Possible, but not needed on the type level, and restricts use
unnecessarily.

Andre'
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Thiago Macieira 
On Monday, 20 April 2020 08:04:38 MDT Matthew Woehlke wrote:
> On 19/04/2020 08.23, André Pönitz wrote:
> > QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
> > TypeB based e.g. on alphabetical order of their .typeName().
> > 
> > If wanted, this can be refined to make e.g. all integral types comparable.
> 
> No:
> 
>int{5} <=> JsonObject{...} => lesser
>int{5} <=> long{3} => greater
>long{3} <=> JsonObject{...} => greater
> 
> ...oops.

I think, whatever we do, we will keep numeric type conversion. That code is 
already there and is the least contentious part of the comparison code. When I 
wrote it half a decade ago, I was very careful to follow the C++ integral type 
promotion rules. The only new thing I'd do to that code is fix the comparison 
of a negative qint64 to a quint64: type promotion rules and expectation don't 
match (there's a new function in C++ to do that comparison in the "expected" 
manner; can't recall the name).

I would argue that a new QVariant shouldn't even have multiple, different 
numeric types, but just one or two (integral and floating point), like 
QCborValue does. But since QVariant is built on top of QMetaType, which is 
supposed to relate to concrete types in C++ so you can manipulate them in an 
erased manner, that's not possible.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Thiago Macieira 
On Monday, 20 April 2020 03:28:48 MDT Florian Bruhin wrote:
> FWIW that's the choice Python had taken with Python 2 (ordering different
> types by their type name). It was widely regarded as a bad decision and
> replaced by a TypeError exception in Python 3.

Interesting. Do you have more information on why it is regarded a bad 
decision? A PEP, hopefully?

Either solution can be dealt with by the surrounding code. If one wants not to 
sort across types and QVariant does, then all you need to do is to compare the 
types before. If one want to sort by type and QVariant doesn't, then one needs 
to convert to a specific common type before issuing the comparisons.

The pros of having that conversion inside QVariant is that it reduces the 
chance of someone getting it wrong. This reduces code duplication in favour of 
a well-tested implementation.

The drawback is that it might not be the order you want because the conversion 
isnt the one you wanted. Some conversions are lossy and may result in spurious 
or nonsensical comparisons. That means some applications may need to deploy 
their own conversion code regardless of what QVariant does. For those and the 
others that don't need comparisons across types, QVariant has unnecessary 
complexity.

So, again, it boils down to choice. I'm really interested in Python's 
rationale to see if it applies to us too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Matthew Woehlke 

On 19/04/2020 08.23, André Pönitz wrote:

QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().

If wanted, this can be refined to make e.g. all integral types comparable.


No:

  int{5} <=> JsonObject{...} => lesser
  int{5} <=> long{3} => greater
  long{3} <=> JsonObject{...} => greater

...oops.

You'd have to make all integral types sort before (or after) all other 
types, but then you're back to not having a reliable ordering by type name.


It makes *much* more sense that some comparisons just come back 
"incomparable".


--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Bernhard Lindner 
Hi!

> In other cases this such silent breakage is called "bug fix"
> and has a positive connotation.

YMMD :-)

For this reason, Qt does not have a formal requirements engineering 
sub-process. Without
requirements, everything is debatable and you can pretty much do what you want. 
Including
defining bugs and features :-)

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread André Pönitz 
On Mon, Apr 20, 2020 at 11:40:24AM +0200, Giuseppe D'Angelo via Interest wrote:
> Before bikeshedding on the actual semantics we _want_ to have: if they
> don't 100% match the ones we have right now, then it's a silent breakage
> for end-users, which is a very bad idea.

In other cases this such silent breakage is called "bug fix"
and has a positive connotation.

> So, if we ever want to have the relational operators in QVariant with
> "better" semantics, we need an upgrade path that clearly signals the
> breakage. Any proposals for that?

One could start with free functions qSomehowLessThan() doing that, and
use them in cases where the current convenience conversions and
operator==() implementations fail. 

Andre'
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Bernhard Lindner 

> So, if we ever want to have the relational operators in QVariant with
> "better" semantics, we need an upgrade path that clearly signals the
> breakage. Any proposals for that?

qFatal() would be a clear signal. It depends from the actual solution if all 
changes
result in qFatal.

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Giuseppe D'Angelo via Interest 

(Sorry, this was meant to go to the list!)

On 4/19/20 2:21 PM, Allan Sandfeld Jensen wrote:

I don't think we need "incomparable" here.

QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().

If wanted, this can be refined to make e.g. all integral types comparable.


What about non-integral types? QVariants can't really be anything but weakly
ordered as I see it, as some of the things it contains are either non-
comparable or weakly ordered themselves.



Before bikeshedding on the actual semantics we _want_ to have: if they
don't 100% match the ones we have right now, then it's a silent breakage
for end-users, which is a very bad idea.

So, if we ever want to have the relational operators in QVariant with
"better" semantics, we need an upgrade path that clearly signals the
breakage. Any proposals for that?

My 2 c,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Florian Bruhin 
On Sun, Apr 19, 2020 at 12:42:16PM -0300, Thiago Macieira wrote:
> On Sunday, 19 April 2020 09:39:40 -03 André Pönitz wrote:
> > > What about non-integral types?
> > 
> > They are compared by typeName(). So any QChar would be less-than any
> > QRegularExpression.
> 
> We can order by type, but I don't think we should. But that's a choice.

FWIW that's the choice Python had taken with Python 2 (ordering different types
by their type name). It was widely regarded as a bad decision and replaced by a
TypeError exception in Python 3.

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-20 Thread Yves Maurischat 

Hi Yuri,

I assume you're implementing a QSortFilterProxyModel for sorting and 
filtering: you can reimplement QSortFilterProxyModel::lessThan() 
. Basically 
you'll do the following (in pseudo code):


bool  YourSortModel::lessThan(constQModelIndex   
&/source_left/, constQModelIndex   
&/source_right/)
{
auto left =/source_left.data(someRole);/
auto right=/source_right//.data(///someRole/);/

return (left.toByteArray() < right.toByteArray());
}



Mit freundlichen Grüßen | Kind regards,

*Yves Maurischat*
Senior Software Engineer

basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 870 589 -144 | Fax: -199
yves.maurisc...@basyskom.com | www.basyskom.com

Handelsregister: Darmstadt HRB 9352
Geschaeftsfuehrende Partner: Heike Ziegler, Alexander Sorg


Am 18.04.2020 um 11:43 schrieb evilruff:

Hi Thiago,

I am happy ro redesign my code, but how then sorting/filtering models 
will work? As data() returns QVariant. Or you plan to use setSorting 
based on lambda's and std::function to provide strict types sorting?


And what if from API point of view user want just to specify column 
without aware of data types.


Am I missing something? Woukd really appreceate if you can point me to 
some direction to look at.



Regards,
Yuri


Relational comparisons with QVariant are deprecated in 5.15 and will be
removed because they are a misfeaure. Redesign your code so your 
question does

not need to be asked.






___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread Thiago Macieira 
On Sunday, 19 April 2020 00:59:25 -03 Nyall Dawson wrote:
> Just to clarify -- are you saying it's been deprecated IN qt 6, or
> removed in qt 6?

Deprecated in 5.15. It's not been removed in Qt 6 yet but it might be.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread Thiago Macieira 
On Sunday, 19 April 2020 08:05:05 -03 André Pönitz wrote:
> > We can't do that right now because we can't rely on C++20. In fact, no
> > current compiler supports the spaceship operator. So that has to be Qt 7.
> 
> How comes the spaceship operator comes into play here?
> 
> It's syntactical sugar and in some cases an optimization, but has no
> concepual powers exceeding those of operator<().

It's an optimisation: the QMetaType vtable for the type can contain a single 
entry (spaceship) instead of one for equality and one for ordering. In 
addition, we can determine how the element can compare by inspecting the 
return type.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread Thiago Macieira 
On Sunday, 19 April 2020 09:39:40 -03 André Pönitz wrote:
> > What about non-integral types?
> 
> They are compared by typeName(). So any QChar would be less-than any
> QRegularExpression.

We can order by type, but I don't think we should. But that's a choice.

As Allan said, QVariant to QVariant comparison needs to be weak, partial 
ordering already. Some types aren't orderable (QSize, QPoint, etc.) and some 
have non-comparable values (double, float).

> On the inner level the situation is up to the actual type, that's no
> different than today, and would also not be affected by disallowing
> comparisons between different types.

Some different types I think we should compare: all numeric ones. We already 
have the proper promotion rules implemented. But I don't think we should 
convert anything else, not even QPoint to QPointF.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread Allan Sandfeld Jensen 
On Sonntag, 19. April 2020 14:39:40 CEST André Pönitz wrote:
> On Sun, Apr 19, 2020 at 02:21:39PM +0200, Allan Sandfeld Jensen wrote:
> > > I don't think we need "incomparable" here.
> > > 
> > > QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA
> > > and
> > > TypeB based e.g. on alphabetical order of their .typeName().
> > > 
> > > If wanted, this can be refined to make e.g. all integral types
> > > comparable.
> > 
> > What about non-integral types?
> 
> They are compared by typeName(). So any QChar would be less-than any
> QRegularExpression.
> 
> > QVariants can't really be anything but weakly ordered as I see it,
> > as some of the things it contains are either non- comparable or
> > weakly ordered themselves.
> 
> On the inner level the situation is up to the actual type, that's no
> different than today, and would also not be affected by disallowing
> comparisons between different types.
> 
Yes, but in C++20 terms the comparison operators still need to return types of 
https://en.cppreference.com/w/cpp/utility/compare/partial_ordering[1] 

But all that really isn't possible before C++20 as I see it.

'Allan


[1] https://en.cppreference.com/w/cpp/utility/compare/partial_ordering
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread André Pönitz 
On Sun, Apr 19, 2020 at 02:21:39PM +0200, Allan Sandfeld Jensen wrote:
> > I don't think we need "incomparable" here.
> > 
> > QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
> > TypeB based e.g. on alphabetical order of their .typeName().
> > 
> > If wanted, this can be refined to make e.g. all integral types comparable.
> > 
> What about non-integral types? 

They are compared by typeName(). So any QChar would be less-than any
QRegularExpression. 

> QVariants can't really be anything but weakly ordered as I see it,
> as some of the things it contains are either non- comparable or
> weakly ordered themselves.

On the inner level the situation is up to the actual type, that's no
different than today, and would also not be affected by disallowing
comparisons between different types. 

Andre'
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread Allan Sandfeld Jensen 
On Sonntag, 19. April 2020 14:23:56 CEST André Pönitz wrote:
> On Sun, Apr 19, 2020 at 01:28:32PM +0200, Allan Sandfeld Jensen wrote:
> > On Sonntag, 19. April 2020 13:05:05 CEST André Pönitz wrote:
> > > On Sat, Apr 18, 2020 at 09:44:40PM -0300, Thiago Macieira wrote:
> > > > On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest
> > 
> > wrote:
> > > > > I guess that's the reason for dropping the comparisons in 6.0 and,
> > > > > eventually, reintroduce it in 7.0. With the hope that we've learned
> > > > > the
> > > > > lesson and proceed at _specifying_ the behaviour before implementing
> > > > > it.
> > > > 
> > > > Indeed, and implement the QVariant comparator on top of each
> > > > underlying
> > > > type's spaceship operator. That way, we could order elements of the
> > > > same
> > > > type. For mismatched types, QVariant can return
> > > > std::partial_ordering::unordered.
> > > > 
> > > > We can't do that right now because we can't rely on C++20. In fact, no
> > > > current compiler supports the spaceship operator. So that has to be Qt
> > > > 7.
> > > 
> > > How comes the spaceship operator comes into play here?
> > > 
> > > It's syntactical sugar and in some cases an optimization, but has no
> > > concepual powers exceeding those of operator<().
> > 
> > It has the concept of weak ordering, it isn't just returning true or
> > false,
> > but an enum of a specific type, which so we can report two elements as
> > incomparable if they are not of comparable types.
> 
> I don't think we need "incomparable" here.
> 
> QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
> TypeB based e.g. on alphabetical order of their .typeName().
> 
> If wanted, this can be refined to make e.g. all integral types comparable.
> 
What about non-integral types? QVariants can't really be anything but weakly 
ordered as I see it, as some of the things it contains are either non-
comparable or weakly ordered themselves.

'Allan



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread André Pönitz 
On Sun, Apr 19, 2020 at 01:28:32PM +0200, Allan Sandfeld Jensen wrote:
> On Sonntag, 19. April 2020 13:05:05 CEST André Pönitz wrote:
> > On Sat, Apr 18, 2020 at 09:44:40PM -0300, Thiago Macieira wrote:
> > > On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest 
> wrote:
> > > > I guess that's the reason for dropping the comparisons in 6.0 and,
> > > > eventually, reintroduce it in 7.0. With the hope that we've learned the
> > > > lesson and proceed at _specifying_ the behaviour before implementing it.
> > > 
> > > Indeed, and implement the QVariant comparator on top of each underlying
> > > type's spaceship operator. That way, we could order elements of the same
> > > type. For mismatched types, QVariant can return
> > > std::partial_ordering::unordered.
> > > 
> > > We can't do that right now because we can't rely on C++20. In fact, no
> > > current compiler supports the spaceship operator. So that has to be Qt 7.
> > 
> > How comes the spaceship operator comes into play here?
> > 
> > It's syntactical sugar and in some cases an optimization, but has no
> > concepual powers exceeding those of operator<().
> > 
> It has the concept of weak ordering, it isn't just returning true or false, 
> but an enum of a specific type, which so we can report two elements as 
> incomparable if they are not of comparable types. 

I don't think we need "incomparable" here.

QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().

If wanted, this can be refined to make e.g. all integral types comparable.

Andre'
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread Allan Sandfeld Jensen 
On Sonntag, 19. April 2020 13:05:05 CEST André Pönitz wrote:
> On Sat, Apr 18, 2020 at 09:44:40PM -0300, Thiago Macieira wrote:
> > On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest 
wrote:
> > > I guess that's the reason for dropping the comparisons in 6.0 and,
> > > eventually, reintroduce it in 7.0. With the hope that we've learned the
> > > lesson and proceed at _specifying_ the behaviour before implementing it.
> > 
> > Indeed, and implement the QVariant comparator on top of each underlying
> > type's spaceship operator. That way, we could order elements of the same
> > type. For mismatched types, QVariant can return
> > std::partial_ordering::unordered.
> > 
> > We can't do that right now because we can't rely on C++20. In fact, no
> > current compiler supports the spaceship operator. So that has to be Qt 7.
> 
> How comes the spaceship operator comes into play here?
> 
> It's syntactical sugar and in some cases an optimization, but has no
> concepual powers exceeding those of operator<().
> 
It has the concept of weak ordering, it isn't just returning true or false, 
but an enum of a specific type, which so we can report two elements as 
incomparable if they are not of comparable types. 

'Allan


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-19 Thread André Pönitz 
On Sat, Apr 18, 2020 at 09:44:40PM -0300, Thiago Macieira wrote:
> On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest wrote:
> > I guess that's the reason for dropping the comparisons in 6.0 and,
> > eventually, reintroduce it in 7.0. With the hope that we've learned the
> > lesson and proceed at _specifying_ the behaviour before implementing it.
> 
> Indeed, and implement the QVariant comparator on top of each underlying 
> type's 
> spaceship operator. That way, we could order elements of the same type. For 
> mismatched types, QVariant can return std::partial_ordering::unordered.
>
> We can't do that right now because we can't rely on C++20. In fact, no 
> current 
> compiler supports the spaceship operator. So that has to be Qt 7.

How comes the spaceship operator comes into play here?

It's syntactical sugar and in some cases an optimization, but has no concepual
powers exceeding those of operator<().

> For now, the feature is badly implemented and yet too many people are using 
> it.

Right.

> We can't simply remove it without giving fair warning. The warning is given.

Andre'
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Nyall Dawson 
On Sun, 19 Apr 2020 at 10:48, Thiago Macieira  wrote:
>
> On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest wrote:
> > I guess that's the reason for dropping the comparisons in 6.0 and,
> > eventually, reintroduce it in 7.0. With the hope that we've learned the
> > lesson and proceed at _specifying_ the behaviour before implementing it.
>
> Indeed, and implement the QVariant comparator on top of each underlying type's
> spaceship operator. That way, we could order elements of the same type. For
> mismatched types, QVariant can return std::partial_ordering::unordered.
>
> We can't do that right now because we can't rely on C++20. In fact, no current
> compiler supports the spaceship operator. So that has to be Qt 7.
>
> For now, the feature is badly implemented and yet too many people are using
> it. We can't simply remove it without giving fair warning. The warning is
> given.

Just to clarify -- are you saying it's been deprecated IN qt 6, or
removed in qt 6?

Nyall
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Thiago Macieira 
On Saturday, 18 April 2020 12:57:55 -03 Giuseppe D'Angelo via Interest wrote:
> I guess that's the reason for dropping the comparisons in 6.0 and,
> eventually, reintroduce it in 7.0. With the hope that we've learned the
> lesson and proceed at _specifying_ the behaviour before implementing it.

Indeed, and implement the QVariant comparator on top of each underlying type's 
spaceship operator. That way, we could order elements of the same type. For 
mismatched types, QVariant can return std::partial_ordering::unordered.

We can't do that right now because we can't rely on C++20. In fact, no current 
compiler supports the spaceship operator. So that has to be Qt 7.

For now, the feature is badly implemented and yet too many people are using 
it. We can't simply remove it without giving fair warning. The warning is 
given.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread evilruff 
With all respect to Thiago opinion I coldnt agree with it. There is nothing 
wrong at all with forwarding comparison of the values with the same data types 
to original classes within universal coontainer like QVariant as mentioned in 
the previous answer. However I agree that comparing uncomparable should lead to 
qFatal.. Problem is that even if I support idea of clean and tidy architectures 
and designs -main goal of the frameworks is to make life simple and easier to 
the end user -  developer.. I looked in 5.15 sources. Ok idea clear - compare 
logic moved to virtual lessThen of the sortind model with QModelIndex's as 
parameters. Thats exactly an approach i have in my code for now with all extra 
switches to handle what was forgotten in QVariant implementation, but as for me 
its not a way to go. QVariant is a class exists for ages in the Qt and it has 
all the features even now to provide a decent way to compare typed related 
objects it contains including custom implementations.As for me 5.15 
implementation is not better, its just moving same code to other classes 
provoking develor to extra inheritance or to copy paste this code to other 
places where QVariant stored values requires comparation..Why on earth then not 
to change this in existing branches used in production rather then declare that 
its a bad desing. I am not even talking about QtScript which is also QVariant 
based and where it was really convinient way to handle abstract types. I know 
that answer probably will be that we deprecated QtScript decades ago, but again 
up to me thats was one on the worsest decision made although its a bit other 
subject.It would take 15-20 lines of code to add native comparations to already 
existing classes to current QVariant which will make things consistent where of 
course < operator is applicable but only answer received sounds more like... ( 
skipped due to probable violation of some rules).. ;)And as we started about 
versions.. its nice to hear that something going to change in 5.15, 6.0 etc, 
but are Qt developers really assume that stable production code will easily 
'just go' over major branches to update or will start adjusting current designs 
to potentially fullfil some guidelines of far away releases? 
Well, if QVariant::canConvert() says right operand can be converted to type of 
left, thenconvert and compare the result. If it can't convert, behavior should 
be undefined andqFatal() should be called (or whatever Qt 5.15 prefers to do in 
detectable cases ofundefined behavior).___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Bernhard Lindner 
Hi!

> The biggest problem right now is that the behaviour of QVariant 
> comparisons is largely undocumented, that is, dictated by the 
> implementation. Any change to the these behaviours, as sensible as it 
> could be, will lead to silent breakages.

Well, if the chance to create documention during requirements phase was missed 
it should
at least be documented now.

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Bernhard Lindner 
Hi!

> The problem are not missing conversions, but too many conversions.

If it is not possible to document and fix conversions to behave consistently 
(which should
be possible), it still is reasonable to allow >/< comparisons for equal types 
only. That
is easy to implement, simple to document, simple to understand and propably 
better than
removing the feature completely.

However, considering the fact that even ==/!= comparisons with implicit 
conversion do not
work as expected, it is obvious that removing >/< comparison isn't a solution 
to the
underlying problem.

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread André Pönitz 
On Sat, Apr 18, 2020 at 04:53:04PM +0200, Bernhard Lindner wrote:
> Hi!
> 
> > > > Relational comparisons with QVariant are deprecated in 5.15 and will be
> > > > removed because they are a misfeaure.
> > > > Redesign your code so your question does not need to be asked.
> > > 
> > > Could you please explain why comparing two QVariants is a misfeature?
> > 
> > Not comparing for equality. Comparing for ordering.
> >
> > What comes first, QSize(1, 1) or QRegularExpression("^$") ?
> 
> Well, if QVariant::canConvert() says right operand can be converted to type 
> of left, then
> convert and compare the result.

The main problem with QVariant conversions is that in the way they are 
implemented
currently does not make them suitable even for equality comparision, leading to
effects like 

#include 
#include 

int main()
{
QVariant v1 = QString("a");
QVariant v2 = QChar('a');
QVariant v3 = QByteArray("a");

qDebug() << QMap{{v1, 0}, {v2, 0}, {v3, 0}}.size();
qDebug() << QMap{{v2, 0}, {v1, 0}, {v3, 0}}.size();
}

producing

   1
   2

In theory, that's solvable, in practice you will always find someone adding yet
another conversion for "convenience" breaking that again.

> If it can't convert, behavior should be undefined and
> qFatal() should be called (or whatever Qt 5.15 prefers to do in detectable 
> cases of
> undefined behavior).

The problem are not missing conversions, but too many conversions.

Andre'
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Giuseppe D'Angelo via Interest 

Il 18/04/20 16:53, Bernhard Lindner ha scritto:

Not comparing for equality. Comparing for ordering.

What comes first, QSize(1, 1) or QRegularExpression("^$") ?

Well, if QVariant::canConvert() says right operand can be converted to type of 
left, then
convert and compare the result. If it can't convert, behavior should be 
undefined and
qFatal() should be called (or whatever Qt 5.15 prefers to do in detectable 
cases of
undefined behavior).


The biggest problem right now is that the behaviour of QVariant 
comparisons is largely undocumented, that is, dictated by the 
implementation. Any change to the these behaviours, as sensible as it 
could be, will lead to silent breakages.


I guess that's the reason for dropping the comparisons in 6.0 and, 
eventually, reintroduce it in 7.0. With the hope that we've learned the 
lesson and proceed at _specifying_ the behaviour before implementing it.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Bernhard Lindner 
Hi!

> > > Relational comparisons with QVariant are deprecated in 5.15 and will be
> > > removed because they are a misfeaure.
> > > Redesign your code so your question does not need to be asked.
> > 
> > Could you please explain why comparing two QVariants is a misfeature?
> 
> Not comparing for equality. Comparing for ordering.
>
> What comes first, QSize(1, 1) or QRegularExpression("^$") ?

Well, if QVariant::canConvert() says right operand can be converted to type of 
left, then
convert and compare the result. If it can't convert, behavior should be 
undefined and
qFatal() should be called (or whatever Qt 5.15 prefers to do in detectable 
cases of
undefined behavior).

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Jason H 
Probably the best way to handle this is for the model to maintain a map of column affinity, specified as QMetaType::Type, to compare items. The items themselves should also have an individual type. A database application will only need column affinity, a spreadsheet app will need item affinity. Then the model (as part of the model classes ( filter, sort)) should implement the automatic comparisons.

 

Python's repr() function is ideal for this. Not sure how Qt could support this, but I really enjoy repr()

 

 
 

Sent: Saturday, April 18, 2020 at 5:43 AM
From: "evilruff" 
To: interest@qt-project.org
Subject: Re: [Interest] QVariant compare operator



Hi Thiago,

 

I am happy ro redesign my code, but how then sorting/filtering models will work? As data() returns QVariant. Or you plan to use setSorting based on lambda's and std::function to provide strict types sorting?

 

And what if from API point of view user want just to specify column without aware of data types.

 

Am I missing something? Woukd really appreceate if you can point me to some direction to look at. 

 

 

Regards, 

Yuri

 


 

Relational comparisons with QVariant are deprecated in 5.15 and will be
removed because they are a misfeaure. Redesign your code so your question does
not need to be asked.





___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Thiago Macieira 
On Saturday, 18 April 2020 07:28:59 -03 Bernhard Lindner wrote:
> Hi!
> 
> > Relational comparisons with QVariant are deprecated in 5.15 and will be
> > removed because they are a misfeaure.
> > Redesign your code so your question does not need to be asked.
> 
> Could you please explain why comparing two QVariants is a misfeature?

Not comparing for equality. Comparing for ordering.

What comes first, QSize(1, 1) or QRegularExpression("^$") ?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread Bernhard Lindner 
Hi!

> Relational comparisons with QVariant are deprecated in 5.15 and will be 
> removed because they are a misfeaure.
> Redesign your code so your question does not need to be asked.

Could you please explain why comparing two QVariants is a misfeature?

-- 
Best Regards,
Bernhard Lindner

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-18 Thread evilruff 
Hi Thiago,I am happy ro redesign my code, but how then sorting/filtering models 
will work? As data() returns QVariant. Or you plan to use setSorting based on 
lambda's and std::function to provide strict types sorting?And what if from API 
point of view user want just to specify column without aware of data types.Am I 
missing something? Woukd really appreceate if you can point me to some 
direction to look at. Regards, Yuri
Relational comparisons with QVariant are deprecated in 5.15 and will be removed 
because they are a misfeaure. Redesign your code so your question does not need 
to be asked.___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QVariant compare operator

2020-04-17 Thread Thiago Macieira 
On Friday, 17 April 2020 19:15:56 -03 evilruff wrote:
> Hi,Recently I was debugging one of my project and ended up with something
> which really surprise me.Are there any special reasons why QVariant compare

Relational comparisons with QVariant are deprecated in 5.15 and will be 
removed because they are a misfeaure. Redesign your code so your question does 
not need to be asked.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] QVariant compare operator

2020-04-17 Thread evilruff 
Hi,Recently I was debugging one of my project and ended up with something which 
really surprise me.Are there any special reasons why QVariant compare < not 
fully cover appropriate operators from other Qt classes.For example QByteArray 
has own operator < but within QVariant switch QByteArray type just defaults to 
toString() which for QByteArray is toUtf8() leads to fact that if you 
have:QByteArray a,b;Knowning that a < b is true, QVariant(a) < QVariant(b) may 
be false..Thats really really inconvinient especially working with ModelView 
concept which is QVariant based..Sort of workaround might be to allow toString 
custom replacing for Qt classes but still I will really appreceate if somebody 
explains me reasons for such strange concept to implement own comparasion 
within QVariant rather then using already existing 
operators.RegardsYuriОтправлено со смартфона Samsung Galaxy.___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest