Thanks Penn...
Here is my implementation on top of Reactive
That I post also https://github.com/JuliaLang/Reactive.jl/issues/99
using Reactive
Signal() = Reactive.Signal(Bool, false)
typealias Slot Function
function emit(signal::Reactive.Signal, args...; kwargs...)
push!(signal, !signal.value)
end
function myslot01(value::Bool, args...; kwargs...)
println("$(time()) myslot01 with $args and $kwargs")
end
function myslot02(value::Bool, args...; kwargs...)
println("$(time()) myslot02 with $args and $kwargs")
end
function myslot03(value::Bool, a, b; x=-1, y=-1)
println("$(time()) myslot03 with a=$a b=$b x=$x y=$y")
end
function connect(signal::Reactive.Signal, slot::Slot)
preserve(map(slot, signal))
end
function is_connected(signal::Reactive.Signal, slot::Slot)
# ToDo
end
#function disconnect(signal::Signal, slot::Slot)
#ERROR: LoadError: TypeError: Tuple: in parameter, expected Type{T},
got Function
#end
stop_modified = Signal()
connect(stop_modified, myslot01)
connect(stop_modified, myslot02)
#connect(stop_modified, myslot03)
emit(stop_modified, 1, 2, x=3, y=4)
#sleep(0.1)
emit(stop_modified, 10, 20, x=30, y=40)
This implementation have some issue
emit is not able to pass arguments (positionnal arguments and keyword
arguments)
I don't know how to implement is_connected
Removing comments for disconnect raises an error.
If there isn't enough delay between 2 emit calls... slots are not executed
twice as they should !
Any idea to fix these issues ?
Le vendredi 3 juin 2016 00:59:27 UTC+2, Penn Taylor a écrit :
>
> 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?
>>
>>
