On 10/11/2010 11:34 PM, Adem wrote:
Plus, even if it is a paradigm shift, it does not sound as if it will
immediately bring the whole house down.
That is right, but it would need more than a one person team. It of
course would need a new svn branch as well in FPC as in Lazarus. So the
appropriate experts would need to help. I did (most of) an
implementation using code taken from MSE (I consider the quality of this
code extremely high and Martin was very helpful when I worked on his
code. He even refactured his code base to avoid the name "Event" that
was used in a different definition as it is in Lazarus.)
Once it gets incorporated into FPC and proves to be a superior
solution, GUIs can adopt (or adapt for) it in their strides.
What do you think should be considered superior.
This is what I think would be improved;
- an Event Queue would be available in non-Lazarus and in
Lazarus-non-GUI applications (so even MSE could benefit from moving part
of it's code into the FPC RTL)
- additional to the current LCL event mechanism "SendMessage" /
"Procedure ... Message" (which would be implemented on top of the new
one) we would have an RTL based "FireEvent" / "Application.Event"
mechanism that not only fires "Windowish" Events with three 32 Bit
Parameters but Event handlers with multiple marshalized/queued
parameters. A "Procedure...Event" syntax candy could be done on top of that.
- The implementation could be done in a thread save way so that an
Application object could be instantiated by a worker thread and so same
gets its own event queue allowing for inter-thread notification and
RTL-based TTimers, thus allowing for a decent event-driven programming
paradigm in all threads
- the "Event-Queue" code is centralized in the RTL and not
reduplicated in any Widget Type, improving manageability and thus
helping enhancing and debugging it (see: currently broken implementation
for Synchronize and SendMessage in Linux, not yet existing
Delphi-compatible TThread.Queue)
- this could be the base of thread-pool driven implementation of
Prism-compatible parallel loops / future variables by means of the RTL
and appropriate syntax candy. (Other ways of providing parallel
execution can be considered as well)
What will not be improved:
- performance (it supposedly will not be degraded, either), unless we
in fact think about parallel loops or other ways of parallelizing)
- current projects and "Delphi"-code will not benefit (but it of
course will not need any modification)
I don't have much hope that the maintainers of the different Widget Type
implementations agree that this is a viable improvement.
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
