Sampling only happens with Reactive if you explicitly use the `sampleon`
function. Otherwise, you just map a function onto a Signal to get a new
Signal. When the first Signal changes, the second Signal changes too.
There's no sampling or polling going on in the normal case.
I'm in no way involved with the development of Reactive, but I think an
imperative signals/slots package would work best as something separate from
Reactive. I tend to think of Reactive as allowing me to declaratively build
"value circuits". If I change the value of this thing over here, the value
of everything else connected to it automatically changes. Conceptually, you
don't *tell* other things a value has changed; it's all passive propagation.
With the imperative signals/slots libraries I've used (Qt 4.x, Qt 5.x,
Boost, and my own managed signals/slots implementation on top of Boost), a
pretty common pattern is to send out a signal with signature
void foo( );
This is essentially broadcasting "foo has happened!". Consider the use of
"clicked()" in Qt. That sort of completely imperative use (no value sent,
no value returned) is harder to do with Reactive. Well, it's fairly ugly
anyway:
using Reactive
foo = Signal(Void)
# Ugly part #1
# Emit is only meaningful for Void signals;
# anything else would simply push a new value into its signal,
# but pushing Void into a Void signal is conceptually nonsense.
function emit(sig)
push!(sig, Void)
end
# Ugly part #2
# Even though the signal we're interested in is a Void signal, our slot
# has to accept an argument: the Void that the signal "sends"
function myslot01( _ )
println("myslot01 called")
end
# Ugly part #3
# Since Reactive.map results in a new signal that we don't care about,
# we have to wrap the "connection" in `preserve` to prevent the GC
# from killing the connection. Not sure how to break this
# connection later should we desire to....
preserve(map(myslot01, foo))
emit(stop_modified)
Like I said, fairly ugly.
Hope that helps,
Penn
On Thursday, June 2, 2016 at 5:10:20 AM UTC-5, Bart Janssens wrote:
>
> Hello,
>
> I would also be interested to know how and if this kind of functionality
> relates to Reactive.jl. Looking at the docs for Reactive, it seems it was
> designed for "continuous" signals. In Reactive, sampling seems to be
> needed, while in a classical signal/slot implementation (such as in Qt)
> slots are linked to a signal and called whenever the signal is emitted,
> i.e. changes value.
>
> So would the way forward for the system described by OP be to extend
> Reactive (if needed), or should this be a separate package?
>
> Cheers,
>
> Bart
>
> On Tuesday, May 31, 2016 at 2:17:54 AM UTC+2, Steven G. Johnson wrote:
>>
>> Reactive.jl?
>
>
