Re: [fpc-devel] "Signals"
Working on the docs at the moment. Trying to make a new release before my travel to ITDevCon. I will do 3 sessions covering different aspects of Mitov.Runtime there. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Schnell Sent: Monday, September 29, 2014 12:44 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] "Signals" On 09/26/2014 10:00 PM, Boian Mitov wrote: We already implement equivalent of signals as I mentioned in Mitov.Runtime, however they are anonymous methods based, and we call them TMultiProc but they are the same thing. I even showed a code snippet in another post. Interesting stuff !! Is there any docs available ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
In fact (to avoid an inconsistency with implementing TApplication.QueueAsyncCall) I suggested that I could do a (rather simple) patch for the future release of the RTL that provides a more appropriate Queue-feeding function than TThread.Queue. This attempt had been discouraged. Seemingly opening the TThread event queue for use by the LCL is considered opening a can of worms. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 10:00 PM, Boian Mitov wrote: We already implement equivalent of signals as I mentioned in Mitov.Runtime, however they are anonymous methods based, and we call them TMultiProc but they are the same thing. I even showed a code snippet in another post. Interesting stuff !! Is there any docs available ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
We already implement equivalent of signals as I mentioned in Mitov.Runtime, however they are anonymous methods based, and we call them TMultiProc but they are the same thing. I even showed a code snippet in another post. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Michael Schnell Sent: Friday, September 26, 2014 12:33 AM To: FPC developers' list Subject: [fpc-devel] "Signals" Yesterday, I had a discussion with a colleague about programming languages. He said that he did not like Object-Pascal / fpc because it lacks the concept of "signals" he finds in other languages / libraries. (He is not an expert but discusses on base of rumors he collected.) With "signals" he meant a kind of multi-target events. He described that multiple parts (units) of a program (or even units within a set of sunning programs) can "subscribe" to a signal (or several of them), and whenever anyone "rises" a signal all subscribers get notified and can react. Seemingly the execution line in such a "unit" might be as well the main thread or a worker-thread (or even another task/program) and the event handler can be defined to work on this thread (he did not elaborate if always or optionally a newly created thread can be used). Unfortunately I was not able to come up with a similarly powerful concept available in fpc. Any suggestions ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 9/26/2014 4:51 AM, Mattias Gaertner wrote: On Fri, 26 Sep 2014 10:38:04 +0200 (CEST) Michael Van Canneyt wrote: [...] To allow for doing this with thread, an event queue for worker threads needs to be provided. Huh? WHY ? That's why: https://www.youtube.com/watch?v=BKorP55Aqvg ROTFLMAO!!! i can't count the number of times that i've been in the position of that "expert" in that video... lines are lines and kittens are kittens [smh] :lol: -- NOTE: No off-list assistance is given without prior approval. Please *keep mailing list traffic on the list* unless private contact is specifically requested and granted. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
Thinking harder I remember that I did not send it to the Forum but in a private mail to the one person who seemed interested. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 02:09 PM, Reinier Olislagers wrote: Well, that says a lot, I suppose. As it did work for me, it says that nobody is interested in an ActiveNoGUI Widget Type for Lazarus right now. I can use it with the svn version of fpc if I want to. So I decided to hold off until the released version of fpc does have the "ThreadExtensions" and try to integrate this Widget Type in the LCL. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 26/09/2014 14:04, Michael Schnell wrote: > On 09/26/2014 01:57 PM, Reinier Olislagers wrote: > Moreover I did not find that anybody besides myself has been interested > in this issue. > I seem to remember that I once posted a zip file with a current testing > version (either here or in the Lazarus forum) but got no answer. Well, that says a lot, I suppose. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 01:57 PM, Reinier Olislagers wrote: So why not include your own version of TThread with IFDEFS to check for FPC version so it can be retired when an FPC 2.7.1+ is used/stable? I don't suppose it makes sense to do a version of TThread that does not reside in the rtl / and "classes" even if this somehow might be possible. Moreover I did not find that anybody besides myself has been interested in this issue. I seem to remember that I once posted a zip file with a current testing version (either here or in the Lazarus forum) but got no answer. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 26/09/2014 13:52, Michael Schnell wrote: > On 09/26/2014 01:41 PM, Reinier Olislagers wrote: > As I already pointed out multiple times it works just fine for me, > but can't be included in the LCL as it needs TThread.Queue and same > is not in the released version of fpc and hence not usable for > "normal" users. So why not include your own version of TThread with IFDEFS to check for FPC version so it can be retired when an FPC 2.7.1+ is used/stable? I don't see the problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 01:41 PM, Reinier Olislagers wrote: Which reminds me - how is that library (non-GUI event loop IIRC) coming along? Is there any code repository where interested people can look? As I already pointed out multiple times it works just fine for me, but can't be included in the LCL as it needs TThread.Queue and same is not in the released version of fpc and hence not usable for "normal" users. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 26/09/2014 12:08, Michael Schnell wrote: > On 09/26/2014 11:36 AM, Mark Morgan Lloyd wrote: > Of course the colleague was not able to clearly distinguish between fpc > and Lazarus. But we obviously are in the wrong forum here, as the > "culprit" seems to be the inability of Lazarus LCL to do event driven > programming in threads. Obviously a library with this feature can be > created (the "closed" design of TThread - that includes a single > main-thread event queue - in the RTL might force creating an alternative > Thread container object though.) Which reminds me - how is that library (non-GUI event loop IIRC) coming along? Is there any code repository where interested people can look? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 11:36 AM, Mark Morgan Lloyd wrote: so that we're not groping in the dark based on your account of his recollection of the rumours he's picked up from sources that might not be reliable. I was just trying to help fpc to be a winner (here and elsewhere). ;-) In fact it seems that he was wrong assuming this to be a language feature. The experts here state that it's just library stuff that - of course - can be used / implemented via fpc. Of course the colleague was not able to clearly distinguish between fpc and Lazarus. But we obviously are in the wrong forum here, as the "culprit" seems to be the inability of Lazarus LCL to do event driven programming in threads. Obviously a library with this feature can be created (the "closed" design of TThread - that includes a single main-thread event queue - in the RTL might force creating an alternative Thread container object though.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 11:40 AM, Michael Van Canneyt wrote: That is an implementation detail of Qt. Not so in FPC. Correct. Hence - if you say the signaling stuff is not / should not be a language feature but just a matter of a library (I don't disagree here) fpc is unrelated to this. I feel that fpc would have no problems with an implementation of an environment that allows for more than one thread that features event-driven programming (While Lazarus only allows for a single such "Main"-Thread. mse: I don't know, but I suspect that Martin did think about it.) So DBus is your best bet, since it is widely supported. I believe Qt uses it as well (or can use it). In fact my colleague did mention QT, I did point him to dbus after you mentioned it. dbus seems less bloated (if you don't need the QT GUI stuff). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
2014-09-26 6:37 GMT-03:00 Sven Barth : > Am 26.09.2014 10:58 schrieb "Michael Van Canneyt" >: > > > > If you want asynchronous, or if you want the signal executed in the > context of a thread in case of multiple threads, that is another matter. > > > > Although I am having difficulty seeing how you would decide which signal > must be executed in what thread... an object does not automatically belong > to a thread... > > In Qt it does. Each QObject has a thread it is owned by and thus the > signal handling mechanism knows to which thread to queue to deliver a > signal to a certain object. > This may help: http://qt-project.org/doc/qt-4.8/threads-qobject.html#signals-and-slots-across-threads Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 11:37 AM, Sven Barth wrote:
In Qt it does. Each QObject has a thread it is owned by and thus the
signal handling mechanism knows to which thread to queue to deliver a
signal to a certain object.
Making the appropriate ("signalable") Objects instances of TThread
siblings would do the same trick.
But (as discussed before) with that such TThread-sibling instances would
have to automatically have their own Event queue instance, and would
need to be programmed in an event-driven way (like the main thread in
Lazarus). (In fact this is what I feel in many cases would be the more
appropriate way to do do worker threads anyway: I already suggested a
"TThreadApplication" Type in Lazarus already ages ago)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014, Sven Barth wrote: Am 26.09.2014 10:58 schrieb "Michael Van Canneyt" : > > > > On Fri, 26 Sep 2014, Martin Schreiber wrote: > >> On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote: Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-) >>> >>> >>> It is. Depends on your definition of difficult, of course. >>> >> Or the implemented functionality. > > > Absolutely. A signaling mechanism, synchronous, is not hard. > > If you want asynchronous, or if you want the signal executed in the context of a thread in case of multiple threads, that is another matter. > > Although I am having difficulty seeing how you would decide which signal must be executed in what thread... an object does not automatically belong to a thread... In Qt it does. Each QObject has a thread it is owned by and thus the signal handling mechanism knows to which thread to queue to deliver a signal to a certain object. That is an implementation detail of Qt. Not so in FPC. In each case, if the requirement is that it must work cross-process, then all processes need to use the same protocol. So DBus is your best bet, since it is widely supported. I believe Qt uses it as well (or can use it). Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
Am 26.09.2014 10:58 schrieb "Michael Van Canneyt" : > > > > On Fri, 26 Sep 2014, Martin Schreiber wrote: > >> On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote: Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-) >>> >>> >>> It is. Depends on your definition of difficult, of course. >>> >> Or the implemented functionality. > > > Absolutely. A signaling mechanism, synchronous, is not hard. > > If you want asynchronous, or if you want the signal executed in the context of a thread in case of multiple threads, that is another matter. > > Although I am having difficulty seeing how you would decide which signal must be executed in what thread... an object does not automatically belong to a thread... In Qt it does. Each QObject has a thread it is owned by and thus the signal handling mechanism knows to which thread to queue to deliver a signal to a certain object. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
Michael Schnell wrote: Yesterday, I had a discussion with a colleague about programming languages. He said that he did not like Object-Pascal / fpc because it lacks the concept of "signals" he finds in other languages / libraries. (He is not an expert but discusses on base of rumors he collected.) With "signals" he meant a kind of multi-target events. He described that multiple parts (units) of a program (or even units within a set of sunning programs) can "subscribe" to a signal (or several of them), and whenever anyone "rises" a signal all subscribers get notified and can react. Seemingly the execution line in such a "unit" might be as well the main thread or a worker-thread (or even another task/program) and the event handler can be defined to work on this thread (he did not elaborate if always or optionally a newly created thread can be used). Unfortunately I was not able to come up with a similarly powerful concept available in fpc. Any suggestions ? Yes, get him to state /exactly/ what language he's talking about that provides this facility, so that we're not groping in the dark based on your account of his recollection of the rumours he's picked up from sources that might not be reliable. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014, Michael Schnell wrote: On 09/26/2014 11:11 AM, Michael Van Canneyt wrote: Please look at the link Mattias provided. It's enlightening. In another forum I already used this video as an example myself. Please read my initial post at the top of the thread: the request for sending "Signals" from one thread to one or more others, sender and recipient can be as well the main thread as a worker thread seems rather clear.. Well, if you need that: the cross application requirement makes it rather tricky - threads are easy in comparison - you can use dbus. FPC has bindings for it. No need to reinvent the wheel. I have a class based wrapper around it. I think you can find it somewhere in the list of articles I published. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 11:11 AM, Michael Van Canneyt wrote: Please look at the link Mattias provided. It's enlightening. In another forum I already used this video as an example myself. Please read my initial post at the top of the thread: the request for sending "Signals" from one thread to one or more others, sender and recipient can be as well the main thread as a worker thread seems rather clear.. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 11:12 AM, Michael Van Canneyt wrote: But the signaling mechanism we talked about is obviously asynchronous. This may come as a shock to you, but no, it is not "obvious". ??? I described: sending "Signals" from one thread to one or more others, sender and receipient can be as well the main thread as a worker thread. To me this is "obviously" asynchronous. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014, Michael Schnell wrote: On 09/26/2014 10:58 AM, Michael Van Canneyt wrote: Absolutely. A signaling mechanism, synchronous, is not hard. I suppose an _synchronous_ mechanism can be done on base of or similar to "Dispatch". But the signaling mechanism we talked about is obviously asynchronous. This may come as a shock to you, but no, it is not "obvious". Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014, Michael Schnell wrote: On 09/26/2014 10:38 AM, Michael Van Canneyt wrote: To allow for doing this with thread, an event queue for worker threads needs to be provided. Huh? WHY ? When handling asynchronous Events with a thread, you need an event queue and a mechanism to have the thread sleep until the queue gets not-empty. Sigh When you give specs like 'a signal mechanism', then "asynchronous operation" is *not* automatically implied. In fact, it is a major shift in functionality. Please look at the link Mattias provided. It's enlightening. Please tell the list afterwards which character you are... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 10:58 AM, Michael Van Canneyt wrote: Absolutely. A signaling mechanism, synchronous, is not hard. I suppose an _synchronous_ mechanism can be done on base of or similar to "Dispatch". But the signaling mechanism we talked about is obviously asynchronous. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 10:38 AM, Michael Van Canneyt wrote: To allow for doing this with thread, an event queue for worker threads needs to be provided. Huh? WHY ? When handling asynchronous Events with a thread, you need an event queue and a mechanism to have the thread sleep until the queue gets not-empty. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014, Martin Schreiber wrote: On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote: Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-) It is. Depends on your definition of difficult, of course. Or the implemented functionality. Absolutely. A signaling mechanism, synchronous, is not hard. If you want asynchronous, or if you want the signal executed in the context of a thread in case of multiple threads, that is another matter. Although I am having difficulty seeing how you would decide which signal must be executed in what thread... an object does not automatically belong to a thread... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014 10:38:04 +0200 (CEST) Michael Van Canneyt wrote: >[...] > > To allow for doing this with thread, an event queue for worker threads > > needs > > to be provided. > > Huh? WHY ? That's why: https://www.youtube.com/watch?v=BKorP55Aqvg Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 10:19 AM, Martin Schreiber wrote: Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-) Nice :-) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote: > > Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not > > so easy to implement as it seems. ;-) > > It is. Depends on your definition of difficult, of course. > Or the implemented functionality. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014, Michael Schnell wrote: On 09/26/2014 09:39 AM, Michael Van Canneyt wrote: You can use the Observer pattern; it is in the classes unit. I'll take a look. And to be honest, this is not a language concept, but a library concept. AFAIK he mentioned QT as a library providing this. It can be easily implemented. If so I assume that somebody already did it. Yes, I have. To allow for doing this with thread, an event queue for worker threads needs to be provided. Huh? WHY ? The implementation must be thread safe, but that's about it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014, Martin Schreiber wrote: On Friday 26 September 2014 09:57:43 Michael Schnell wrote: On 09/26/2014 09:39 AM, Michael Van Canneyt wrote: You can use the Observer pattern; it is in the classes unit. I'll take a look. And to be honest, this is not a language concept, but a library concept. AFAIK he mentioned QT as a library providing this. It can be easily implemented. If so I assume that somebody already did it. Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-) It is. Depends on your definition of difficult, of course. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Friday 26 September 2014 09:57:43 Michael Schnell wrote: > On 09/26/2014 09:39 AM, Michael Van Canneyt wrote: > > You can use the Observer pattern; it is in the classes unit. > > I'll take a look. > > > And to be honest, this is not a language concept, but a library concept. > > AFAIK he mentioned QT as a library providing this. > > > It can be easily implemented. > > If so I assume that somebody already did it. > Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On 09/26/2014 09:39 AM, Michael Van Canneyt wrote: You can use the Observer pattern; it is in the classes unit. I'll take a look. And to be honest, this is not a language concept, but a library concept. AFAIK he mentioned QT as a library providing this. It can be easily implemented. If so I assume that somebody already did it. To allow for doing this with thread, an event queue for worker threads needs to be provided. In fact I already did some research on this issue. It does not seem a great problem, but to be decently done, IMHO the event queue code in the RTL should be re-used. But this does not seem to be a concept that is supported by the implementers of the RTL, as no public interface to same is provided. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Signals"
On Fri, 26 Sep 2014, Michael Schnell wrote: Yesterday, I had a discussion with a colleague about programming languages. He said that he did not like Object-Pascal / fpc because it lacks the concept of "signals" he finds in other languages / libraries. (He is not an expert but discusses on base of rumors he collected.) With "signals" he meant a kind of multi-target events. He described that multiple parts (units) of a program (or even units within a set of sunning programs) can "subscribe" to a signal (or several of them), and whenever anyone "rises" a signal all subscribers get notified and can react. Seemingly the execution line in such a "unit" might be as well the main thread or a worker-thread (or even another task/program) and the event handler can be defined to work on this thread (he did not elaborate if always or optionally a newly created thread can be used). Unfortunately I was not able to come up with a similarly powerful concept available in fpc. You can use the Observer pattern; it is in the classes unit. And to be honest, this is not a language concept, but a library concept. It can be easily implemented. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] "Signals"
Yesterday, I had a discussion with a colleague about programming languages. He said that he did not like Object-Pascal / fpc because it lacks the concept of "signals" he finds in other languages / libraries. (He is not an expert but discusses on base of rumors he collected.) With "signals" he meant a kind of multi-target events. He described that multiple parts (units) of a program (or even units within a set of sunning programs) can "subscribe" to a signal (or several of them), and whenever anyone "rises" a signal all subscribers get notified and can react. Seemingly the execution line in such a "unit" might be as well the main thread or a worker-thread (or even another task/program) and the event handler can be defined to work on this thread (he did not elaborate if always or optionally a newly created thread can be used). Unfortunately I was not able to come up with a similarly powerful concept available in fpc. Any suggestions ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
