Re: Implicit actions & program correctness

[deadhacker <gstover@gmail.com>]

On Friday, May 15, 2020 at 12:03:39 PM UTC-7, Jeffrey R. Carter wrote:
> On 5/15/20 7:45 PM, deadhacker wrote:
> > 
> > It makes me wonder what experienced Ada programmers think of work done implicitly by a program.  Have you run into similar practices?  Have you been able to talk people into ending them?
> 
> I'm not clear what you mean by "implicit actions". In Ada, a lot can be done 
> automatically by the process called "elaboration". This is generally considered 
> a good thing. It's not uncommon for everything in significant programs to be 
> done by elaboration.
> 
> On the other hand, elaboration doesn't doe anything that isn't explicitly in the 
> code, so maybe it isn't what you're thinking about.
> 
> On the gripping hand, things like user-defined assignment and indexing and pre- 
> and post-condition testing might be considered implicit actions.
> 
> -- 
> Jeff Carter
> "Who wears beige to a bank robbery?"
> Take the Money and Run
> 144

Hi Jeffrey & everyone.  Here is what I mean by implicit actions

(pseudocode)
class Dinner contains references to Salad, Entre, & Desert.

class Entre contains references to a Meat, a Bread, & whatever else

you get the idea for classes Salad & Desert.

I declare those classes but do NOT write code that creates instances.  I compile & link it all together with my "autowiring" library such as Spring.  When the program fires up, the library sees that I declared all of those classes, so it starts creating instances.  For Dinner, it'll need a Salad, an Entre, & a Desert, so it goes to create instances of them & make sure that the Dinner contains their references.  And since those other classes might also contain references to other classes, it makes those, too.  There are notations in the code or a config file (or both) that tell the framework what classes it's concerned with, but it creates the instances & makes sure they know about each other.

In my opinion, it's a cute trick for experiments, but it's inappropriate for production code, at least long-lived code that'll be the product of many programmers over the years.

More realistically, a web server might have a concept of a chain of filters that operate on a request.  Maybe we have an Authentication filter, an Authorization filter, a MakeSureItsNotSpam filter, & they have to be called in the right order.  When I'm auditing the program, it's difficult to be sure that all the filters are in the correct order or even all are included in the chain.

I'd rather see explicit code like this:
if is spam, error
elsif is not authenticated, redirect to authentication
elsif is not authorized, error
else vend the resource.

Seems that Ada, at least in the books I've been reading, nudges the programmer to work that way, so I was wondering what people with actual Ada experience have to say about it.  Does Ada nudge you to work that way?  And are you glad you do work that way?