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.98.87.71 with SMTP id l68mr16023602pfb.13.1448356085083; Tue, 24 Nov 2015 01:08:05 -0800 (PST) X-Received: by 10.183.3.106 with SMTP id bv10mr345582obd.17.1448356085026; Tue, 24 Nov 2015 01:08:05 -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!news.glorb.com!mv3no1886960igc.0!news-out.google.com!l1ni7286igd.0!nntp.google.com!mv3no1886950igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 24 Nov 2015 01:08:04 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=94.107.233.114; posting-account=6m7axgkAAADBKh082FfZLdYsJ24CXYi5 NNTP-Posting-Host: 94.107.233.114 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <04eb6626-644b-4b16-a329-c35659a9fbe2@googlegroups.com> Subject: Re: operation can be dispatching in only one type From: Serge Robyns Injection-Date: Tue, 24 Nov 2015 09:08:05 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:28517 Date: 2015-11-24T01:08:04-08:00 List-Id: On Monday, 23 November 2015 18:40:57 UTC+1, Jeffrey R. Carter wrote: > On 11/23/2015 03:23 AM, Serge Robyns wrote: > >=20 > Ada has only single dispatch, so an operation can only be a primitive ope= ration > of a single tagged type (the "controlling" type). That's fine as you must have noticed. >=20 > In Ada, neither the parameter name (Self) nor the position of the paramet= er in > the parameter list determine the type for which an operation of a tagged = type > dispatches. Instead, it dispatches on the parameter of a tagged type for = which > it is a primitive operation. [A primitive operation is declared in the sa= me > declarative part as the type (usually a pkg spec).] I didn't know about the position, I honestly believed it had to be the 1st.= I don't know where I read that. Anyway I'm reading now the A-LRM 2012. I= 'm using "Self" as a naming convention. > Since here you have 2 tagged types in the same declarative part, this ope= ration > is primitive for both, which violates the Ada rule. Note that in the stan= dard > containers, type Cursor is not tagged for precisely this reason: They nee= d > operations that take both a container and a cursor as parameters. >=20 > The standard approach to this is to put each tagged type in a separate pk= g: I though that packaging and typing were quite independent and hence this is= why I merged these two types in one package as they form a coherent assemb= ly. I also recall some "advertisement" about that "fact". But it seems no= t to be that fully true. > Another approach is to make one parameter classwide; then it is primitive= for > only one tagged type: Yep, learned about that in a previous post. > A fourth approach is to make one of the types non-tagged, as with Cursor = in the > containers. >=20 > A fifth approach is to make all types non-tagged. This approach causes th= e > fewest problems. >=20 > This is a primitive operation of type account (to use the Ada terminology= ) > because it occurs in account's class structure. Ada has a somewhat idiosy= ncratic > syntax for programming by extension. >=20 This is what I did in the end. The only OO feature I'm now using is DAO in= the business logic part of the application. It really works very well and= it is clean to read. However it would have been nice not to have do aband= on tagged types in general because of the issues above. This is my biggest= "disappointment". I'm not in the camp of everything has to be an object b= ut here I would love to have my main "business" objects be implemented as t= agged types. Like for example creating new specialized versions of the T_A= ccount and per the rules you can only write "type New_T is new Old_T" for t= agged types. I'm fully convinced about Ada's code quality and reliability = but I'm wondering if these types of issues are not what keeps Ada "locked" = into its current niche and failing to gain attraction. This is where it "transpires" that tagged types came in Ada95 and that back= wards compatibility with Ada85 is giving hard time. I recall reading about= the issues of controlled tagged types. Now, other languages have their own issues. When I'm reading about C++ tem= plates it can become really hard. Yesterday I've been trying to figuring o= ut about C++ type traits and how they are constructed. Everything except r= eadable if you ask my opinion. Serge