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,611f4b10cbf9af69 X-Google-Attributes: gid103376,public From: Dave Gibson Subject: Re: Redefinition of Equality (Long) Date: 1996/09/30 Message-ID: <324FD267.954@cis.ohio-state.edu>#1/1 X-Deja-AN: 186226879 references: <52hgmoINN7tg@snoopy.cis.ohio-state.edu> content-type: text/plain; charset=us-ascii organization: The Ohio State University Dept. of Computer and Info. Science mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0 (X11; I; HP-UX A.09.05 9000/715) Date: 1996-09-30T00:00:00+00:00 List-Id: Robert A Duff wrote: > > In article <52hgmoINN7tg@snoopy.cis.ohio-state.edu>, > david scott gibson wrote: > > It seems highly undesirable for "=" to modify its parameters. If you > want to implement "=" in terms of some destructive operations, then you > ought to make a copy of the parameters first. Why is this a problem? Why pay the price of making a copy of an arbitrarily large object when it is not necessary?? (Making a few copies of access values will do.) "=" should, of course, leave the abstract value of its parameters unmodified. It should be the responsibility of the person implementing Set "=" to ensure that. However, I do not see any good reason to prevent the operation from manipulating the value passed in in order to compute the function result - especially if it avoids unnecessary copying. The way I'm writing code, the value passed in is always an access value although this is not visible at the client level. > I certainly agree that functions should allow 'in out' parameters, but > not so you can write evil "=" operations. But even if 'in out' were > allowed, you would still have your problem, because for *tagged* types > an overriding operation has to be subtype conformant with what it's > overriding. Are you saying that a hypothetical 'in out' mode "=" would only overload and not override the automatically generated "=" function? Or would it not even be allowed to overload? Either way, that would be a problem. > (2) About half of the reviewers were rabidly anti-side-effect zealots. > Despite the fact that Ada functions allow side effects on globals, and > on stuff pointed to by parameters, this contingent believed that > preventing *some* forms of side effects (namely, on parameters) is > better than nothing. Well, I'm almost in agreement with them. I'd like to write functions which do not have any side-effects at the abstract level. How this is achieved concretely, however, should not be unduely hampered by the compiler. > I was very much in favor of removing this restricion. And I've found it > frustrating when writing Ada 95 code. I happen to think that *some* > kinds of side effects are OK, and I find it annoying that I have to use > access parameters, and put "aliased" and "'Access" all over the place. The use of access types didn't help me out in this situation because I want to be able to move around object values by exchanging the access values pointing to the objects. I also found it very annoying and distracting placing "aliased" and "'access" all over the place. Thanks for your insights. Dave -- dgibson@cis.ohio-state.edu