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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,CP1252 Path: g2news2.google.com!postnews.google.com!l13g2000yqb.googlegroups.com!not-for-mail From: =?ISO-8859-1?Q?Hibou57_=28Yannick_Duch=EAne=29?= Newsgroups: comp.lang.ada Subject: Re: Tagged type more type safe than access to subprogram ? Date: Thu, 29 Oct 2009 04:00:29 -0700 (PDT) Organization: http://groups.google.com Message-ID: <336a4300-9867-4caf-a8c2-4e75e262e694@l13g2000yqb.googlegroups.com> References: NNTP-Posting-Host: 86.66.190.171 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1256814030 17927 127.0.0.1 (29 Oct 2009 11:00:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 29 Oct 2009 11:00:30 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: l13g2000yqb.googlegroups.com; posting-host=86.66.190.171; posting-account=vrfdLAoAAAAauX_3XwyXEwXCWN3A1l8D User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; fr),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:8836 Date: 2009-10-29T04:00:29-07:00 List-Id: On 28 oct, 09:55, "Dmitry A. Kazakov" wrote: > An access to subprogram is a poor-man's closure. Let's ignore "access" pa= rt > and consider a pure downward closure (as it should have been in Ada). =93 As this should have been in Ada =94 ? What were you to mean ? I've always though real closures are not possible with such structures as Ada provides, except at package level =97 which is especially the case when a package can have multiple instances... but only at package level. Isn't it ? > I argue that a helper type with an abstract primitive subprogram is safer > than a closure, both safer and type-safer. > > The general safety comes from the fact that a closure brings a context wi= th > it, which an object normally does not. An abstract type is better > encapsulated and there is less chances to run into occasional side effect= s. > Even if the side effects are desired I would argue that it is better and > safer to limit them to the object rather than to the closure's context. T= he > crucial point is that closure's effects are "there", while effects on the > object are localized to the object's state, there are "here", at the call > point. > > The type safety is gained through different types derived from the abstra= ct > parent. There might be no difference at the caller side, e.g. whether you > mistakenly call to the closure C1 instead of C2, or mistakenly pass an > instance of S1 instead of S2 (both from the S'Class). Yet it is type safe= r > with regard to the parameters required to construct S2. Its constructor c= an > have a different signature, so that the parameters you pass in order to > create it were different from S1. If I attempt an abstract of your words, and if I've understood you in a right way, it could be : tagged types are safer than accesses to subprograms, because the abstract method of a tagged type is always associated to a suitable context, unlike subprogram, with which ones a single error is immediately turned into a double error =97 the one about the subprogram and the one about the closure which comes with the subprogram reference. This is relevant, indeed. Now I see the deal much better (providing I'm OK with my understanding). I would like to just add two other notes, about flexibility (not safety) : the first one, I think its a good idea to add a Ready function (returning Boolean) to the tagged type, because the tagged type may be extended in a way where it needs setup (useful for peoples who like to add Eiffel-like precondition to their specifications). This seems general enough to me to add this function to any tagged type which is intended to act as an abstract method (and to add an initial default implementation which always return True). And then, about implementation now : if an abstract method is concerned by performance, it is possible to add an alternate batch version belong to the primary abstract method (to run the method on a sequence of parameters, either as input or output). This is a good idea to add it to the same tagged type, as it is deeply related to the =93 normal =94 (un- batched version) of the abstract method (deeply related in many ways, such as required internal data to work, setup, shared part of algorithm, etc). This is another argument pleading in favor of the provided flexible of tagged types over access to subprograms.