Property as member of C++ classes

[DaMilyutin]

(This is branch from discussion #607.)

I've seen come generated code. Properties are private members.
And set_some_property and get_some_property are generated wrappers around private property.
AFAIKG, those are meant to be called in main event loop only.

So, when working with threads the following patterns emerge

        sixtyfps::[blocking_]invoke_from_event_loop([&ui, val] {
            ui->set_some_property(val);
        });
        // or if thread worker
        sixtyfps::[blocking_]invoke_from_event_loop([&ui, update] {
            ui->set_some_property(update(ui->get_some_property()));
        });

To keep window API smaller for user I suggest to make public properties but with extra functionalities on them.
I'd hide all read/write blocking operations under the hood of setter/(assign operator) and getter.
And add unsafe_ set/get methods that are meant to be called only from main event loop.

And I'd add safe update methods for case like ui->set_counter(ui->get_counter() + 1);
What seems nice option to me is to provide updating functor like:
ui->counter.update([](T const& old_val) -> T { return old_val + 1; });

With implementation like:

void Property<T>::update(F f) 
{
    auto p = this;
    sixtyfps::[blocking_]invoke_from_event_loop([p, f] {  // blocking or not?
         auto new_val = f(p->unsafe_get()); // unsafe_get is non-blocking/cheap and called from evnt loop
         p->unsafe_set(new_val); // unsafe_set is non-blocking/cheap and called from evnt loop
    });
} 

Cases for operator+=, operator-=, operator*= and similar can be also implemented as for operator= via update method.

Probably there may be blocking update and non-blocking update.
I'd prefer conventional update to be most safe and others have some prefixes and suffixes.

I believe this idea will reduce boilerplate.
However, user must be cautions when calling from main thread or worker thread.

Let's discuss this idea. Maybe during discussion we'll come up with better design.

Additional idea is to add some property.blocking() method as wrapper. To call blocking operations explicitly.

   ui->counter.blocking() += 1;

   ui->counter += 1; // blocking will deadlock

[tronical]

I'm in favour of finding ways to reduce boiler plate. I'm unsure if adding wrapping magic solves that though.

The pattern of calling

      sixtyfps::[blocking_]invoke_from_event_loop([&ui, val] {
            ui->set_some_property(val);
        });

is indeed suboptimal if called subsequently. I think it's better if the application groups updates together in messages and updates a bunch of properties in one block (invoked from the event loop).

Perhaps the generator code can provide assistance in generating the interfaces for more efficient message passing, from the UI into worker threads and the other way around. I think of a message as information that originates from one or (likely) multiple properties and flows in both ways. The granularity of those is however naturally application dependent.

Some of this can already be achieved by defining structures in .60, creating them and invoking callbacks with them or storing them in properties and setting them from the native code.

[DaMilyutin]

If you want to use messages I think it is possile but one must be cautionus when have multiple worker threads.
Message order matters and some messages must be "glued" together and processed in sequence by small groups.
(As you say term "granularity", I assume you are more experienced in mulithread programming and you probably mean this.)
As for me, these messages can be generated by properties under the hood.

[DaMilyutin]

Alternative on update may be like so:
ui->counter.update([](T& my_val) { ++my_val; });
With implementation like:

void Property<T>::update(F f) 
{
    auto p = this;
    sixtyfps::[blocking_]invoke_from_event_loop([p, f] {  // blocking or not?
         f(p->unsafe_ref()); // `unsafe_ref` is non-blocking/cheap reference to contained data in property
    });
} 

To wrap up this idea. What Property API may look like?

1. There are unsafe methods of property which can be used only in main loop.
2. There are blocking_update and [non-blocking] update methods that work as callbacks to main loop.
3. property has operators = (and +=, -= if make sence for T) implemented via [non-blocking] update.
   Those are safe to use when rhs is not dependant on any property.
4. There is wrapper which calls blocking methods. It has operators like = (and +=, -=) via blocking_update.
5. Update methods implementation may send messages instead of accessing data. This is done to improve granularity.
   This actually can be, probably, done via sixtyfps::[blocking_]invoke_from_event_loop itself or similar function.

[ogoffart]

We also need to think about real usecase. Just updating a counter is not something that happen so often in a real application application. Usually the logic is a bit more complex and involve a bit more properties that need to be updated together. Hence i think having a scope with a invoke_from_event_loop is not too bad

[DaMilyutin]

I agree that updating multiple properties at once is better to do with invoke_from_event_loop.

I'd actually add unsafe wrapper for this case. So

sixtyfps::invoke_from_event_loop([p1 = ui->p1.unsafe(), p2 = ui->p2.unsafe(),... ]() 
{ //do smth with captured in quite natural way
p1 += p2; // unsafe wrapper just access data rerefed to property without any other operations
... //other operations with properties
} );

This can be also done with blocking wrapper as follows:

// non blocking invoke_from_event_loop from same thread
ui->p1.update([p2 = ui->p2.unsafe()]() { p1 += p2; }); // body is called from event loop

// blocking_invoke_from_event_loop to call from worker thread
ui->p1.blocking().update([p2 = ui->p2.unsafe()]() { p1 += p2; }); // body is called from event loop

BTW, in this design, blocking rule is same as invoke_from_event_loop.
And there can be only one blocking property in update or it'll probably deadlock.