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 10.236.1.37 with SMTP id 25mr31943769yhc.25.1417024307309; Wed, 26 Nov 2014 09:51:47 -0800 (PST) X-Received: by 10.140.25.142 with SMTP id 14mr22632qgt.26.1417024307290; Wed, 26 Nov 2014 09:51:47 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!w8no2541643qac.0!news-out.google.com!m4ni576qag.1!nntp.google.com!w8no2541641qac.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 26 Nov 2014 09:51:47 -0800 (PST) In-Reply-To: <1kqnn4e05fbl2$.1wv2gk39uwsha.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=24.197.113.215; posting-account=Ies7ywoAAACcdHZMiIRy0M84lcJvfxwg NNTP-Posting-Host: 24.197.113.215 References: <7d9r3whe43z8$.1f2l3n5cz0zh0$.dlg@40tude.net> <1tlppwq452jbq$.d1y3trfego8b$.dlg@40tude.net> <1xbl1kdcf9at5.1dfv4py4kvx0o.dlg@40tude.net> <1kqnn4e05fbl2$.1wv2gk39uwsha.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7e46e76e-b1e3-4933-8f37-0e9c85f5f728@googlegroups.com> Subject: Re: Should weak counted reference be able to be strengthened? From: brbarkstrom@gmail.com Injection-Date: Wed, 26 Nov 2014 17:51:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:23747 Date: 2014-11-26T09:51:47-08:00 List-Id: On Wednesday, November 26, 2014 4:28:07 AM UTC-5, Dmitry A. Kazakov wrote: > On Tue, 25 Nov 2014 15:49:49 -0600, Randy Brukardt wrote: > > > "Dmitry A. Kazakov" wrote in message > > > ... > >> Instead of introducing "crazy beautiful" implicit dereference, Ada 2012 > >> should have delegation support for the patterns like this. > > > > Depending heavily on interfaces is a sure way to madness. :-) > > > > But the real problem here is I don't see any way to add "delegation support" > > that actually saves much over the explicit version that you showed. We > > certainly don't want *everything* to delegate (it has to be declared somehow > > for the particular operations in question), > > Everything of course, unless explicitly overridden. > > > and because of overloading we > > have to at least have the complete profile. That means an awful lot of > > typing (and source text to read), and lots of chance for errors. > > Yes, which is why delegation and other means to compose overridden > operations are needed. > > The programmer should be able to define things which happen implicitly when > for example: > > type X is new Integer; > > This implicitly defines a lot of operations composed like: > > function "abs" (Value : X) return X > = X (abs (Integer (Value)); > > It is not much different from how "sane" implicit dereference would work > > type Y is access Integer; > > function "abs" (Value : Y) return Integer > = abs (Value.all); > > I don't know how to describe such things syntactically. That is a > challenge. > > > In a sense, Ada 2012 has delegation support as one can use expression > > functions that way. > > Yes, they could be viewed this way, but in my view they are too powerful. > What I want is a more limited mechanism of composition which could be > easily checked. The limitation is that the old body is used with an > epilogue and/or a prologue and conversions are applied to the arguments > and/or the result. If the body has to be changed, it must be overridden. > > -- > Regards, > Dmitry A. Kazakov This dialogue reminds me of a substantial conversation currently going on in the library community with respect to long-term (200 years) information preservation with transformational migration. The problem gets even more interesting in federated archives (think DSA across the Internet). The life of digital files (or databases) is more or less limited by the lifecycle of hardware or software obsolescence. So, if your favorite documentation formatting vendor decides to deprecate the previous format, what's an archive to do - transform the original or throw it out? If the archive throws the document out, it might still want a reference to it to maintain a provenance track that can aid in proving authenticity of the transformed original. Furthermore, that community has tendencies to want some centralized authority to provide references to the "unique" "authentic original." [Never mind the fact that such an authority - raking in money even - is a single point of failue.] So, if the archive throws out that original file (or it becomes unreadable) and the community seems to think that a backup copy is "not authentic" because only the one "original" copy was the "authentic" one there may need to be some mechanism to notify users of the history of the changes. The weak references in the previous posts appear to be like the "centralized" site's reference to the archive copy that they think is the "authentic original" (but now unreadable or deleted). The latter is presumably the strong reference. I'm still inclined to think Ada has a significant potential market in the long-term information preservation business. The requirements for loss per year are into the number of nines we think about for life-critical software systems. After looking at the posts here, I am pretty sure that the arguments about weak and strong references in Ada are similar (and perhaps mathematically identical) to the issues the library community is arguing about. There may even be some light their discussion could shed on the one in the Ada community. [Besides, if this small discussion could help solve a "big" problem, that would be even more fun.] Bruce B.