Hi,
The idea looks awesome.
This is our rough plan of how we'd like to address one aspect of QML and Qt
> Quick today. We are looking forward to any feedback and questions to help
> us review and refine this design.
>
I was wondering is there any plans to use this pattern in other Qt modules?
Also It could be a nice topic to discuss on Qt Contributor Summit.
Best regards,
Mikhail
On Tue, 1 Oct 2019 at 16:57, Eike Ziller <eike.zil...@qt.io> wrote:
>
>
> > On 1. Oct 2019, at 16:12, Jason H <jh...@gmx.com> wrote:
> >
> >
> >> I’m all for a more declarative coding style also in C++.
> >> I’m wondering if we are re-inventing part of Reactive Programing a la
> ReactiveX with QProperty, though?
> >>
> >> The above looks similar to (sodium-cxx):
> >>
> >> cell_sink<QString> surname("John");
> >> cell_sink<QString> lastname("Smith”);
> >> cell<QString> fullname = surname.lift(
> >> lastname, [](QString s, QString l) { return s + " " + l; });
> >>
> >> qDebug() << fullname.sample();
> >> surname.send("Emma");
> >> qDebug() << fullname.sample();
> >>
> >> or (RxJS):
> >>
> >> var surname = new BehaviorSubject("John");
> >> var lastname = new BehaviorSubject("Smith");
> >> var fullname = new BehaviorSubject();
> >> r.combineLatest(surname, lastname).pipe(map(([s, l]) => { return s +
> " " + l; })).subscribe(fullname);
> >>
> >> console.log(fullname.getValue());
> >> surname.next("Emma”);
> >> console.log(fullname.getValue());
> >>
> >> What is the relation of QProperty to Reactive Programing, in which ways
> can we orient QProperty on what is done there, or learn from insights in
> that field?
> >
> >> Using "fullname.listen([](QString s) { qDebug() << s; });" (or
> "fullname.subscribe(s => console.log(s));”) instead of the explicit logging
> in the example above
> >> will print “John Smith”, whereas using change event listeners always
> requires special handling of the initial value.
> >
> > I would (naively) think that this would be done by creating a
> default-constructed value, then setting it?
>
> Looks like I wasn’t clear with what I mean with this. The difference is
>
>
> cell_sink<QString> surname("John");
> cell_sink<QString> lastname("Smith”);
> cell<QString> fullname = surname.lift(
> lastname, [](QString s, QString l) { return s + " " + l; });
>
> fullname.listen([](QString s) { qDebug() << s; });
> surname.send("Emma”);
>
> prints
>
> John Smith
> Emma Smith
>
> (same for RxJS and subscribe),
> whereas it looks like with the current patch for QProperty
>
> QProperty<QString> surname("John");
> QProperty<QString> lastname("Smith");
>
> QProperty<QString> fullname;
> fullname.setBinding([&]() { return surname() + " " + lastname(); });
>
> Qt::onPropertyChanged(fullname, [](QString s) { qDebug() << s; })
> surname = "Emma”;
>
> prints just
>
> Emma Smith
>
> So you basically always have to write the special code that does whatever
> you want to do with the property when it changes, also with the initial
> value.
> (sodium even has transactions, but that’s a different story ;) )
>
> > So I've used knockout and observables, and at the same time used Qt, and
> I always preferred QML over the bindings with that framework.
> >
> > I'm wondering (out loud) if we aren't kinda talking about a opposite of
> QGadget for our classes - one where it can just emit a changed() event for
> applicable setters. I'm not sure how much of moc would have to be brought
> in - obviously we wouldn't want it on every class...?
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
>
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
