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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bd40601768eaf8fd X-Google-Attributes: gid103376,public From: Mark Lundquist Subject: "cast away const" (was Re: Array of Variant Records Question...) Date: 1999/09/14 Message-ID: <37DE871E.4249A231@rational.com>#1/1 X-Deja-AN: 525059897 Content-Transfer-Encoding: 7bit References: <7r5vh3$imu1@svlss.lmms.lmco.com> <37d6a45c@news1.prserv.net> <37d6ccb6@news1.prserv.net> <7r77i8$i08$1@nnrp1.deja.com> <37d7c116@news1.prserv.net> <7r8t21$ov5$1@nnrp1.deja.com> <37d822a1@news1.prserv.net> <7r9r4u$fsc$1@nnrp1.deja.com> <37D96965.81045235@rational.com> <37d9a3b7@news1.prserv.net> Organization: Rational Software Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-09-14T00:00:00+00:00 List-Id: Matthew Heaney wrote: > In article <37D96965.81045235@rational.com> , Mark Lundquist > wrote: > > >> That seems just *too* kludgy to me, and very implemention > >> dependent, wouldn't it be better to just introduce in out > >> and out parameters for functions (but we know that one won't > >> fly ...) > >> > > > > Why would that be necessary, since functions already can have access > > parameters? OK, the actual must denote an aliased view... > > It's like I said in another post: sometimes you have an operation that is > publicly in-mode, but privately in-out. > > The function Random is declared this way: > > function Random (G : in Generator) return Result_Subtype; > > From an abstract point of view, Generator provides a stream of random > numbers, and function Random simply returns successive values from this > stream. The stream is just out there, in the ether, and no modification of > this stream is required. At this level of abstraction, something like a self-advancing iterator would look similar. It's not that much of a stretch, even though everyone knows that the iterator must have state and that the state must change when the iterator advances. But it's not like you really want to say "extract the value, and oh by the way update the iterator, too..." You really just mean, "I'm giving you the iterator to operate on", i.e., in-mode. > > From an implementation point of view, however, invoking the function Random > changes the state of the Generator. That's why you need a way to "cast away > const," to be able to change state of an object whose parameter mode is in. I've been trying think from your "abstract point of view" about objects whose type view is limited private. What exactly can "state" mean from this perspective? You don't know about its components, can't assign it, can't test equality. Isn't the idea "state" of an opaque object kind of problematic? Suppose that in the bodies of primitives of types whose partial view is limited private, an in-mode parameter declared a variable view instead of a constant view (in other words, if the differentiation of in-mode vs. in-out-mode were annulled). A bizzarre idea on the face of it, but -- what would be lost? (Not that I think this would actually be a good idea...) Why do we have parameter modes in the first place? It's so that intent is communicated explicitly, esp. to programmers who are going to code against the subprogram declaration. We could have only mode in-out, as is the case in Java -- then it's this expressiveness that would be lost, but in the case of limited private types it sort of collapses. If the language adopted your cast-away-const operation, should it be available only for types whose partial view is limited private, and then only where the full view is visible (i.e. in the body?)