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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9d303864ae4c70ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-13 02:30:38 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: wojtek@power.com.pl (Wojtek Narczynski) Newsgroups: comp.lang.ada Subject: Re: Reprise: 'in out' parameters for functions Date: 13 Apr 2004 02:30:37 -0700 Organization: http://groups.google.com Message-ID: <5ad0dd8a.0404130130.66d5e721@posting.google.com> References: <5ad0dd8a.0404090512.15af2908@posting.google.com> <5ad0dd8a.0404091828.6e79bb4e@posting.google.com> <5ad0dd8a.0404100735.7b2a8317@posting.google.com> NNTP-Posting-Host: 83.27.17.147 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1081848637 6768 127.0.0.1 (13 Apr 2004 09:30:37 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 13 Apr 2004 09:30:37 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:7038 Date: 2004-04-13T02:30:37-07:00 List-Id: Dimitry, You silently refused to say what abstraction inversion is according to you :-) > However it is questionable, whether protected objects have a higher level of > abstraction than semaphores. They are more generic but no less fundamental. Well, let's look at them as manual (semaphores) vs. automated (protected objects). > BTW, for your protected counters example, (4) would be enough: > > protected type Counter is > procedure Inc; -- Increments this counter > private > Value : Integer := 0; > end Counter; > > procedure Inc_One (First : in out Counter); > -- Same as Inc, but uses functional notation > procedure Inc_Two (First, Second : in out Counter); > -- Increments two counters atomically, starts two protected actions, > -- one per argument Cool. > First of all I do not count compile time solutions for true solutions. A > true one would include an ability to work with dimensioned values which > units are unknown at compile time. A simpliest possible example is to write > a physicist calculator. Then we're talking about two distinct things. I am talking about a compile time solution only. > OK, there are only two ways I know of, if you find a third way... The first way can be viewed as an incarnation of the second. Or you can ensure that there are no runtime exceptions. > How it differs from (2)? You just replaced the official mechanism of > inheritance with some hard-wired other. Discriminants are just special kind > of members. It differst in that it can be implemented, because there are no pointers to inexistent trampolines, only (immutable, integer) values. > This won't work. The exception out of Catch_It will be propagated *after* > "end Sample". So you cannot catch it here! In any point you could, the type > B will be already finalized. So you would have a zombie object of an > unexisting type. Well, this is how it goes with exceptions. That's why the "type" should be limited (in ordinary sense) to only: declaration, raising / construction, catching and extracting immutable values in handlers. > Why (1) cannot work here? The only real problem with (1) I can see, is that > the exception type does not have ranges or other forms of subsets. One need > some syntactic suggar to define a set of exceptions which could be then > named in "when". Feel free to perceive my 'code' as syntactic sugar. Regards, Wojtek