[fpc-pascal] Delphi compatible anonymous functions

Dmitry Boyarintsev skalogryz.lists at gmail.com
Mon May 26 17:02:06 CEST 2014


On Fri, May 16, 2014 at 11:45 AM, Craig Peterson
<craig at scootersoftware.com>wrote:

> 2) Our application has multiple independent top-level windows, like a
> web browser.  There is no "MainForm".  Each window can show modal
> dialogs that only disable that specific window.
>
> [snip]
>
>
Ugh, but with anonymous functions replacing ShowMyDialog vs ShowMyDialogDone,
you're in much worse positions.
It's likely that you would have to the duplicate code.
I'd assume that "after modal dialog" code is somehow matches to some other
code in the system.

Model-View-Controller pattern comes into play.
The dialog itself is just a way to get a confirmation from a user to do an
actions.
It's likely that the same action could take place without a confirmation
from a user.

So, with anonymous functions, you'd need to duplicate the same action code
across the system. (Anonymous functions are just for here-and-now usage). No
reason to enumerate the cons of code duplication.

----

No directly related to usage of anonymous functions...

...and please note, I'm not trying to criticize your work, but give an
excuses for my point of view...

Using a threading for GUI control is generally bad idea. Most of standard
GUI APIs (OSX, Windows, *nixes) have a note in 90% of their functions - "do
not use in multiple threads". Introducing threads to handle GUI is
potentially dangerous (due to all threading syncing issues) and an
overhead. Most of solutions doesn't really need threads, as well as usage
of threads increases resources consumption.

...back to anonymous:

So making a choice of changing the code to use Fibers, rather than using
ShowDialog / DoneDialog was not so good after all.
Right now you're in position to change the code code from Fibers to
something more portable...
And yet again using ShowDialog / DoneDialog is one of the options.

Another point to use anonymous functions is storing of "State" that could
be later use in processing the resulting code.
The compiler is doing for you it's good and bad. Good - you don't need to
write any extra code, Bad - pretty much anything could go into the "state",
even the things you don't need to be there (or do need to be there, but not
there at all).
So, I do think that storing the state explicitly is a better option, even
though extra lines of code would be required.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20140526/94b5dd1a/attachment.html>


More information about the fpc-pascal mailing list