From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: Top 10 Worst C# Features Date: Sun, 6 Sep 2015 12:45:14 +0200 Organization: A noiseless patient Spider Message-ID: References: Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 6 Sep 2015 10:43:27 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="f7972c5513f369b1efd12133304f7abd"; logging-data="4128"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX186gaTfcmJga4wAgcyA2BXy1aeH7YvqEaY=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: Cancel-Lock: sha1:EYSyjGBQYzfm/t8f66hsyCE8/Kk= Xref: news.eternal-september.org comp.lang.ada:27715 Date: 2015-09-06T12:45:14+02:00 List-Id: On 05.09.15 08:45, Niklas Holsti wrote: > On 15-09-05 00:34 , Randy Brukardt wrote: >> "Georg Bauhaus" wrote in message >> news:msbhc8$6qq$1@dont-email.me... >> ... >>> So, while there is no problem with >>> either a very flexible O-O system emulated in C, or with having the Ada >>> compiler help with earlier binding, both approaches do not handle events >>> in the language. >> >> I have not the slightest clue as to what "handling events in the language" >> would look like, assuming Ada doesn't have it. > > It seems to me that Georg's "events" are rather like the "pointcuts" or "join points" in aspect-oriented programming (https://en.wikipedia.org/wiki/Aspect-oriented_programming) where some computation is added to certain points in a program without modifying the original source code, and instead coding the new computation separately and somehow declaratively defining how the original and new computations are interleaved at run-time at the join points. These "aspects" (of AOP) would come to mind, but rather than focus on them, I wanted to start from a more inclusive definition of "event", perhaps a little broader than those "aspects", but applicable to a number of programming situations. A definition that can lead the way to language for writing a program's reaction to specific "events". Summarily: Some words of source text would then express "event handling", but neither by way of having "_Handler" as the suffix of some primitive operation's name, nor by the event being an exception, say, and event handling being the statements of an exception handler. Exploring a bit: First and foremost, programmers need to be oriented when being asked about events and how their programs handle them, so that's an aspect to keep in mind when defining "event". If you think about both programming situations (involving humans) and also about programs that run (involving technology like clocks, mice, touch screens, networks, thermometers), then "event" becomes the name of quite many different ideas. However, they all share certain qualities: 1) that of being tied to one single point in space-time 2) that of having economic impact 3) that of being recurring problems in need of a solution ad 1) while (1) happens to agree with what dictionaries say, there is limited support for the property of being single in the Ada language. More so if there would be other sorts of things single, besides event handlers. The support that Ada offers is not addressing events in particular. (Ada is not unique here.) If there is a chance that some event requires a 1:1 mapping in the source text, or in the mind of a programmer being asked about it, then just a bit of general Ada language paired with conventions is all there is. ad 2), imagine a programmer needing to answer questions of the kind "What happens if A?". Can they just point at some place in the source text? What will they find, and how? I guess it is some table-like thing, or some more or less implicit connection of types. These two "traces" of event handling both would contain hints at the parts of the program involved in handling the event "A". Managing this "cross referencing structure" is tedious and costly. (No surprise that GUI programming is considered tricky; it is full of patterns.) If a program does not provide any of this (Gordian spaghetti), then long hours might pass until programmers can answer after studying their program once again. (I am assuming that a majority of GUI programs is not modeled after some real specification. Unfortunately.) Also, when developing a program that handles events, there is no specific guidance by the language; there are libraries that make use of some of the language's features. Of necessity, this creates idiosyncrasies. This state of the art might be good when selling proprietary class libraries, but engineers and project leaders may want something more standard for this very standard programming problem, lest they become "part of the business". (At whose cost?) ad 3) a "problematic" event is an easily named entity; like whenever input channel X14 is delivering data, the program's behavior should be such-and-such, possibly depending further on such-and-such. Or behavior is unexpected. Now, in general,Without these events, many programs would be pointless. Still, language-wise, solutions aren't directly available: programmers rely on class libraries or similar. But solutions need to be found again and again, so as to have programs that handle anything at all. In case of unexpected behavior, solving the problem means modifying the program. But how, if someone else has written the program and used this or that convention? Tasks to the rescue? What can you learn from a task's interface that you couldn't learn from a type's interface? There is one additional bit, viz. independent execution. Does it help event handling? Not according to Aaron Hillegass, who explains that many activities seen to be concurrent can actually be handled conveniently by programming to the run-loop. (I believe some OS design guys also suggest non-communicating processes, but don't remember the name of their project.) A last idea: GUI design programs are a visualization of some event handling, Or rather, they show the stage for event handling. But either way, somehow events are present there. So, GUI design programs use somewhat formal definitions of how objects should be tied together for handling events. They produce some manifestations of "event handling". Is this kind of formalization inaccessible to programming languages?