On 5/26/2014 10:02 AM, Dmitry Boyarintsev wrote:
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.
Dmitry, no offense, but you're making a lot of assumptions about our
code with no basis to do so, and I'm honestly not interested in getting
into a philosophical debate about the "correct" way to develop
software. There are cases where anonymous methods will work well and
cases where we'll have to split it up. It's a tool that I'd like to
have available, not something I'm going to cram where it doesn't belong.
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.
Fibers are cooperative threads, not pre-emptive ones. They're the way
GUI APIs worked in the past (Windows 3.1, MacOS Classic) and GUI APIs
generally still support them just fine. Recent releases of OS X have
started having trouble with it, but older ones worked just fine. There
are no synchronization issues because there isn't more than one running
at the same time.
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.
Cocoa already has what I'm asking for built in to Objective C language
and the Cocoa/sheets API. Many of the functions that show dialogs, that
previously would have had ShowDialog/DoneDialog behavior, accept
Objective C "blocks" now, which are very similar to how anonymous
methods would work in this context.
In any case, we've already done the ShowDialog/DoneDialog thing and it
was unpleasant to work with and resulted code that was much harder to
understand.
Anonymous functions are bad for unit testing.
Why? Because they do exist only at the place of the call and depends
on the state of at the time the call.
And thus they cannot be tested separately without the caller.
*GUIs* are bad for unit testing. *Threading* is bad for unit testing.
Anonymous functions are an implementation detail and are no better or
worse for testing than ShowDialog/DoneDialog or OpenMP would be. In the
cases where we'd use it for things like parallel loops, I'd test the
outer function as a whole, and the inner functions that it calls. I
don't need to unit test the anonymous function separately just because
it has "function" in it's name. You might as well be arguing that I
should break out every "for" loop and "if" statement into its own
function that I can test it separately.
Having an ability to test a complex code separately (outside the
execution environment/application) is a big benefit.
Again, you're assuming things about the testability and structure of our
code that have nothing to do with the discussion at hand.
What if you switch from OmniThreadLibrary to OpenMP (or whatever other
threading library) that doesn't provide support for anonymous functions.
What if you'd need to write a separate application, that doesn't have
the requirement to use threads.
Using the regular code (in procedures or methods) reduces the number
of changes you'd need to do.
Switching from OmniThreadLibrary to some eventual OpenMP implementation
would involve removing the anonymous function syntax and turning it into
a regular begin..end block for a "parallel for" loop. That wouldn't
involve any visible changes to the objects themselves because that's all
encapsulated in the outer function call.
The chances of our code being reused in something that doesn't use
threads is non-existent, and irrelevant either way.
I've mentioned it before OmniThreadLibrary doesn't require you to use
anonymous functions.
Even if that's true, it would significantly reduce the expressiveness of
the resulting code, and I don't know how true it is because the author
has specifically said that he doesn't support FPC because of how
intrinsic anonymous functions are to the design.
--
Craig Peterson
Scooter Software
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
