Re: Top 10 Worst C# Features

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 15-09-05 00:34 , Randy Brukardt wrote:
> "Georg Bauhaus" <bauhaus@futureapps.invalid> 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
       .      @       .