On 2010-10-12 11:47, Michael Schnell wrote:
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.
These things usually do.
But, you seem to have made some headway and that appears to a good point
to start from/with.
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.)
Can't sepak on behalf of anyone but I doubt you will be denied a brach
--taht's what I gatehered from Vincent's words ["no 'political power'
needed."]
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.
What you've listed below --plus that a solution will be available for
non-Lazarus and in Lazarus-non-GUI applications.
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)
Good.
- 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.
Good.
- 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
Good.
- 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)
Good.
- 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)
Good.
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)
So, no loss/damage there.
- current projects and "Delphi"-code will not benefit (but it of
course will not need any modification)
That's good enough for me. If anyone wants to use this new code, s/he
would have to add the necessary glue code using IFDEFs, right? If so, I
can't see any damage there either.
I don't have much hope that the maintainers of the different Widget
Type implementations agree that this is a viable improvement.
My hope/guess is that they may want to modify/extend it in time to cover
their specialized needs (if any); but, having a universal/common code
should benefit them/everybody too.
All in good time.
Cheers,
Adem
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
