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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable 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!feeder.eternal-september.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Top 10 Worst C# Features Date: Sat, 5 Sep 2015 09:45:43 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net +SOP5F9aFVtRSpfcBBPBdg8DLtjcZ9oD6rB7wUfXp8LzEiZldJ Cancel-Lock: sha1:t7Ttd1lhdiqVSBLO41UZ0CMf2qE= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:27707 Date: 2015-09-05T09:45:43+03:00 List-Id: 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. Ada has three features that are similar to this: controlled types, run-time constraint checks, and predicate checks. By making a type controlled, implicit calls of Initialize, Adjust, and Finalize are added at specific points (Georg's "events") in the program. By adding constraints to a type, or predicates to a type or operation, implicit checks ("calls") of those constraints and predicates are added at specific points in the program. However, in aspect-oriented programming the implicitly invoked, new computation is not meant to affect the original computation, but to implement some other linked computation, another aspect of the application. Aspect-oriented programming aims to let programmers define more such pointcuts/events and added computation, for application-specific purposes, and thereby isolate the different "aspects" of the program -- a new sort of modularity and separation of concerns. > "Events" to me are just calls > (dynamic control flow), and I don't see anything sensible that would make > calls "better". Perhaps a lack of imagination on my part. I have long wished for an easier way to return multiple results from a call, especially when the set of results that is really available depends on the run-time outcome of the call, for example on whether the called operation succeeded or failed in some way. At present, to return multiple results from a call, the callee either has to have multiple "out" parameters, or an "out" parameter that is a record type with multiple components. The caller then has to declare her own variables to stand as actual parameters, even if these variables are used only to receive the outputs of this call. If the set of available outputs depends on the outcome of the call, some of the "out" parameters, or some of the components of the "out" record, are often irrelevant and meaningless in some outcomes. For example, if a procedure that searches for an item based on a key fails to find the item, it must return both a "not found" status and an irrelevant, dummy item value. A variant-record "out" parameter can be used to hide the irrelevant item component in such cases, but this adds complexity to the declaration of the record type, and again it will often be the case that this record type is used only for this one procedure and its calls. I have vague ideas that it should be possible to declare, in a procedure's parameter profile, the various outcomes that are possible (found, not found, ...) and which outputs are available in which outcomes. Then it should be possible to call a procedure in a way that opens a block that implicitly starts with a case statement and separates into different branches for different outcomes, with the available "out" parameters directly accessible (as constant objects) in each branch without the caller having to declare her own local variables just for use as actual "outs". Alternatively, the outputs of the call could be implicitly organised like a variant record, with a designated output playing the role of discriminant and case selector. In addition to the variant-record (or class-wide) "out" parameter, Ada has two ways to implement such things: - Different outcomes of a procedure can be signalled by propagating an exception from the call, but this is an extreme all-or-nothing method: if an exception is propagated, the only output from the call is the identity of the exception (and possible side effects). - Outputs of a computation can be made available to a caller, without the caller having to declare "out" variables, by implementing the computation in the elaboration block in the body of a generic package, which has generic formal objects corresponding to the formal "in" and "in out" parameters of the computation, and declares public variables corresponding to the "out" parameters of the computation. To "call" this computation, the "caller" instantiates the generic, and can then access the public variables of the instance, with the values computed at elaboration of the instance, without explicitly declaring her own variables for use as "outs". But I'm sure that most programmers would consider this to be a weird misuse of the generic facility. Further, the instantiation must be done as a declaration, not as a statement, and the "out" variables can seldom be declared constant, because the computation is often too complex to be done in the declaration of the generic package. In a more functional-programming approach, a procedure could be made to "return" its outputs by calling different "continuation" procedures (given as "in" parameters) for the different outcomes; each such continuation procedure could have its own set of "in" parameters corresponding to the "outs" available from the original procedure in this outcome. This would be rather far from the procedural Ada style, but perhaps it could be used as the internal implementation of what I proposed above, even if the source syntax does not look like continuations. > Opportunity for what, madness? Event-driven GUI programming is just one step > short of madness as it is, Ooh, strong agreement here... but I don't think Georg means such events. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .