<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 5/26/2014 10:02 AM, Dmitry
Boyarintsev wrote:<br>
</div>
<blockquote
cite="mid:CAMpTZrfP7W0F9bEc1m7PrXeFgjynVDdoyDPby+=Cfhvs90zLSQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">Ugh, but with anonymous functions
replacing <span
style="font-family:arial,sans-serif;font-size:13px">ShowMyDialog
vs </span><span
style="font-family:arial,sans-serif;font-size:13px">ShowMyDialogDone,
you're in much worse positions.</span>
<div><span
style="font-family:arial,sans-serif;font-size:13px">It's
likely that you would have to the duplicate code. </span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">I'd
assume that </span><span
style="font-family:arial,sans-serif;font-size:13px">"</span><span
style="font-family:arial,sans-serif;font-size:13px">after
modal dialog" code is somehow matches to some other code
in the system.</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">Model-View-Controller
pattern comes into play.</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">The
dialog itself is just a way to get a confirmation from a
user to do an actions.</span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px">It's
likely that the same action could take place without a
confirmation from a user. </span></div>
<div><span
style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div>
<div><font face="arial, sans-serif">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). </font><span
style="font-family:arial,sans-serif">No reason to
enumerate the cons of code duplication.</span></div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAMpTZrfP7W0F9bEc1m7PrXeFgjynVDdoyDPby+=Cfhvs90zLSQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAMpTZrfP7W0F9bEc1m7PrXeFgjynVDdoyDPby+=Cfhvs90zLSQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">So making a choice of changing the
code to use Fibers, rather than using ShowDialog /
DoneDialog was not so good after all.<br>
<div>Right now you're in position to change the code code
from Fibers to something more portable... <br>
</div>
<div>And yet again using ShowDialog / DoneDialog is one of
the options. </div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite">
<div>Anonymous functions are bad for unit testing.<br>
</div>
<div>Why? Because they do exist only at the place of the call and
depends on the state of at the time the call.</div>
<div>And thus they cannot be tested separately without the caller.</div>
</blockquote>
<br>
*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.<br>
<br>
<blockquote type="cite">
<div>Having an ability to test a complex code separately (outside
the execution environment/application) is a big benefit.</div>
</blockquote>
<br>
Again, you're assuming things about the testability and structure of
our code that have nothing to do with the discussion at hand.<br>
<br>
<blockquote type="cite">What if you switch from OmniThreadLibrary to
OpenMP (or whatever other threading library) that doesn't provide
support for anonymous functions.
<div>What if you'd need to write a separate application, that
doesn't have the requirement to use threads.</div>
<div>Using the regular code (in procedures or methods) reduces the
number of changes you'd need to do. <br>
</div>
</blockquote>
<br>
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.<br>
<br>
The chances of our code being reused in something that doesn't use
threads is non-existent, and irrelevant either way.<br>
<br>
<blockquote type="cite">
<div>I've mentioned it before OmniThreadLibrary doesn't require
you to use anonymous functions.</div>
</blockquote>
<br>
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.<br>
<br>
-- <br>
Craig Peterson<br>
Scooter Software<br>
</body>
</html>