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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:ad4:556a:: with SMTP id w10mr5452874qvy.100.1589573598996; Fri, 15 May 2020 13:13:18 -0700 (PDT) X-Received: by 2002:a05:6830:1e39:: with SMTP id t25mr3535416otr.114.1589573598553; Fri, 15 May 2020 13:13:18 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 15 May 2020 13:13:18 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=2600:100f:b03c:445e:e43e:25d2:1af1:f8e2; posting-account=pQzPUgkAAAAOiiJHd16-n1B6leDCaI3_ NNTP-Posting-Host: 2600:100f:b03c:445e:e43e:25d2:1af1:f8e2 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3c545096-d000-4d09-b3fe-ad8530632457@googlegroups.com> Subject: Re: Implicit actions & program correctness From: deadhacker Injection-Date: Fri, 15 May 2020 20:13:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:58699 Date: 2020-05-15T13:13:18-07:00 List-Id: 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: > >=20 > > It makes me wonder what experienced Ada programmers think of work done = implicitly by a program. Have you run into similar practices? Have you be= en able to talk people into ending them? >=20 > I'm not clear what you mean by "implicit actions". In Ada, a lot can be d= one=20 > automatically by the process called "elaboration". This is generally cons= idered=20 > a good thing. It's not uncommon for everything in significant programs to= be=20 > done by elaboration. >=20 > On the other hand, elaboration doesn't doe anything that isn't explicitly= in the=20 > code, so maybe it isn't what you're thinking about. >=20 > On the gripping hand, things like user-defined assignment and indexing an= d pre-=20 > and post-condition testing might be considered implicit actions. >=20 > --=20 > 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 co= mpile & 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 cl= asses, 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 wh= at classes it's concerned with, but it creates the instances & makes sure t= hey know about each other. In my opinion, it's a cute trick for experiments, but it's inappropriate fo= r 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 Aut= horization 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 program= mer to work that way, so I was wondering what people with actual Ada experi= ence have to say about it. Does Ada nudge you to work that way? And are y= ou glad you do work that way?