[fpc-pascal] Delphi compatible anonymous functions

[Craig Peterson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20140526/07d652ef/attachment.html>