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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7d83a6223f4f2443 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news.germany.com!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Run-time accessibility checks (was: Construction initialization problem) Date: Thu, 11 Dec 2008 16:15:39 -0600 Organization: Jacob Sparre Andersen Message-ID: References: NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1229033859 8222 69.95.181.76 (11 Dec 2008 22:17:39 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 11 Dec 2008 22:17:39 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Xref: g2news2.google.com comp.lang.ada:3936 Date: 2008-12-11T16:15:39-06:00 List-Id: > "Dmitry A. Kazakov" wrote > My solution is inheritance, disliked so much. If you want > a referential type to be a substitute for the target type, then the > referential > type simply must inherit to the target. (We don't need "all", though it > can be preserved using some intermediate referential type.) Well, this doesn't make any sense to me at all. And the following example doesn't help; you've made it the *same* type, which is definitely not what you want. The result of dereferencing an access value is a *different* type, with *different* operations. I don't *want* interchangability!! ... > Because Ref_Type is not abstract, you will have to override all primitive > operations of Target_Type, and assignment must be a primitive operation, > and components getter/setters of, in case Target_Type were a record type, > must be as well. That sounds like a maintenance headache (any change must be replicated everywhere. That became such a pain for the Claw Builder program that it almost ground development on it to a halt.) ... >> You certainly can't have a procedure ":=" to do assignment in because of >> discrimant-dependent components. > ":=" is a statement. What I would do is to define *two* primitive > subprograms the compiler will use in order to compose *one* ":=". The > first operation will determine the discriminants, the second will continue > with those known. That's not the problem; the problem is that components appear and disappear, and there is no way to assign them. And there is no way in Ada to just set the discriminants without giving values to the components as well; that is a fundamental invariant of the language which I don't think can be changed without making everything erroneous. ... > Records are not iterated. If we want a container to support iterations, > that must be an abstract array. It also was getter and setters: > function "()" (A : Abstract_Array_Type; I : Index_Type) return > Element_Type is abstract; procedure "()" (A : in out Abstract_Array_Type; > I : Index_Type; E : Element_Type) is abstract; That's not flexible enough for iteration; the index can be anything (it need not have an inherent ordering; it surely cannot be restricted to a discrete type) and thus just having this interface does not allow iteration. There also is very little chance of such an interface being supported in Ada, if I read the feelings of the group well enough. One concern I've heard is that there is no practical way to support this for slicing (again, because the index does not necessarily have ordering). Personally, I'd give up slicing for this sort of abstraction, but I don't think that will fly. Another concern is that almost all of the existing predefined packages would have to be scrapped and replaced to make any use of this (especially the string packages). But people aren't willing to do that ("insufficiently broken"), even if there is plenty of evidence that we could do a lot better for those packages. >> And it also isn't very flexible -- where does the Cursor of a container >> go?? > To me to the recycle bin. *BUT* there is no any problem with cursors, > absolutely. A cursors is a pair. The first component is a type derived > from the container's interface (a reference to the container), the second > component is the container's index. Done! The cursor is the index in the model you have here. And it already is a pair (container, access to something). Not sure what you dislike about them; they've have the same semantics if not the same name. (I was talking about a record selector interface, which makes more sense for getting individual elements.) What *cannot* be the case is that the index is required to be some sort of discrete type. That would require a map to translate said index into some sort of access to the actual element. But that would be silly, especially for map containers (you'd have to go through two maps to find anything, and for what??) But the real problem in all of these things you've suggested is that they are all technically by-copy for reading. If that is all you want, the existing Ada containers do that just fine. The problem is that if the elements are large, copying them may be very expensive, so a by-reference access method is reading. That's the core of the problem I'm trying to address (because I think there is a chance that people will view it as significant enough to deal with). Functions returning values of a type *do not* provide any solution to that (and cannot). Randy.