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,924aad49bcf9e4e7 X-Google-Attributes: gid103376,public From: Dave Gibson Subject: Re: Cumbersome Polymorphism Date: 1997/01/28 Message-ID: <32EE2269.41C67EA6@cis.ohio-state.edu>#1/1 X-Deja-AN: 212754449 references: <32E7ABE8.3BF3@eurocontrol.fr> <32ECF2A3.6371@watson.ibm.com> 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; SunOS 4.1.3 sun4c) Date: 1997-01-28T00:00:00+00:00 List-Id: > > However, it seems that in order to make a very simple use of > > polymorphism, I have been obliged to introduce access types. > > Yes, this is generally the case in Ada 95. Right. Access types do seem necessary for inheritance-style inclusion polymorphism required for dynamic binding in Ada. However, access types are not necessary to achieve generics-based parametric polymorhphism. While generics without exposed use of access types only provide static binding in Ada, this approach can have a number of advantages (assuming a good generics-savy compiler). > > And now by bringing in access types I have imported the problems > > that go with them. > > You are using an access type in a very restricted and disciplined way. > I'm not sure what you mean by "the problems that go with them", but the > fact that undisciplined use of access types may cause problems is > irrelevant. Your solution does not involve any such problems. Well, even if you have a strong discipline that avoids aliasing-related reasoning problems which access types can introduce, I personally think that the code is just more difficult to read and understand when access types are used as much as dynamic dispatching in Ada seems to require. > > However, as is well known, the problem with requiring the user > > of a type to perform explicit deallocation is that he may forget > > to do so somewhere in the code, resulting in a memory leak. > > I don't understand the problem. The need for the deallocation operation > is encapsulated in the package. The writer of the package ensures that > there is never more than one object allocated. The user of the type > never has to know about it. Indeed, the declaration of your access type > ought to be moved out of the package declaration and into the package > body. Yep. That's an important part of a strong discipline for software component engineering. Dave -- dgibson@cis.ohio-state.edu