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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,5d4ade2fd8fd67c6 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Legit Warnings or not Date: Sat, 6 Aug 2011 10:23:00 +0200 Organization: cbb software GmbH Message-ID: References: <531193e0-3305-4292-9ed8-0176226c1d00@x12g2000yql.googlegroups.com> <1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net> <1hi6gva8jhf7o.tq1yp29jn3qu.dlg@40tude.net> <110nibt4tsn7q.162t6eli286tt.dlg@40tude.net> <1wg90w555yp7f.1lhp1szkc0cu5$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: XI7GGoYbKkSGXZj73XTz2g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news1.google.com comp.lang.ada:20484 Date: 2011-08-06T10:23:00+02:00 List-Id: On Fri, 5 Aug 2011 18:57:43 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message >> Unconstrained to S'Class? >> >> type S is new T with ...; >> type A is array (1..1) of S'Class; >> X : T; >> Y : A; >> begin >> T'Class (Y (1)) := X; -- Is this OK? > > No, of course not. Unconstrained to S'Class is right. [...] >> So S'Class, a component will have a different treatment than S'Class a >> parameter? When passed to a subprogram it suddenly becomes constrained? > > Huh? The only time S'Class is "constrained" is when it is a constant. [...] >> Right, accessibility rules is an evil, but if you allow unconstrained >> S'Class, actually implicitly constrained to something somewhere, then these >> implicit constraints must be handled somehow, and there is no other way to >> do this than by accessibility rules. > > I don't see any implicit constraints. If there are any, they ought to be > eliminated. Then: procedure Carcinogenic (X : in out T'Class) is Y : T; begin X := T; end Carcinogenic; Z : S'Class; -- Constrained to S'Class? begin Carcinogenic (T'Class (Z)); -- Ignore the constraint! [ Your idea is to make all classes subtypes of some huge dynamic type. This is not a workable type model as so many OOPLs already showed. ] >>>> [The behavior of types upon composition is a very non-trivial issue.] >>> >>> I would not make any change there; to the extent that it is a problem now it >>> would stay that way. >> >> But you have to address it in array slices and in all other rules >> concerning type and subtype equivalence. You could ignore them for T vs. S, >> because these are different types, but you cannot do this for differently >> constrained class-wide subtypes, e.g. S'Class(<>) vs. S'Class + fixed tag. > > "Fixed tag"? No such thing for a variable. (And the rules for constants > handle the other cases.) My entire point is that there are no constrained > class-wide subtypes. You must have them constrained in order to honor type-specific arguments passed to class-wide operations: Z : S; begin Carcinogenic (Z); When you lift a constraint, you have to check it dynamically. Compare: procedure Foo (X : in out String) is begin X := "abc"; end Foo; Z : String (1..80); begin Foo (Z); >> I mean the cases of composition sharing components. I don't know how usable >> the new "aliased" parameter subtype in Ada 2012 is, but presently there is >> a big problem of getting rid of unnecessary copying. All container >> implementations try to eliminate this overhead. In my view on the language >> design it is OK, because the type system must be small, but have flexible >> interfaces. Your approach is the opposite, clumsy interfaces, much >> manipulation behind them. But where is the promised performance? Nowhere, >> huge S'Class are intended to be copied on any occasion! > > What promised performance? If you don't want the components to be copied, > then they can't be components! That's been True in Ada since the beginning, > and I can't imagine trying to change that. > > But performance doesn't matter to 90% of the code; readability, > maintainability, and the avoidance of errors are much more important. Right, then your argument that the compiler could do something better than the programmer was invalid. > Requiring the user to manually create, copy, and destroy objects is far more > error prone than building it into the language. Right, but the language forces manual manipulation, because interface and implementation are not properly separated. The developer of a type must expose all dirty washes to the user. > (This is the same reason why > I am so strongly opposed to having any access types in the interface of an > object.) Again, right, but this requires means to enforce identity semantics in the interfaces. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de