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,381db495fa3adf75 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!feeder.news-service.com!news.astraweb.com!border5.newsrouter.astraweb.com!border2.nntp.ams.giganews.com!nntp.giganews.com!feeder2.news.saunalahti.fi!fi.sn.net!newsfeed2.fi.sn.net!news.song.fi!not-for-mail Date: Fri, 13 Mar 2009 12:58:05 +0200 From: Niklas Holsti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Package hierarchy. Extensibility. References: <91c9292b-d661-4744-bed2-b9c8a6305196@d19g2000yqb.googlegroups.com> <49b8b91d$0$14980$4f793bc4@news.tdc.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <49ba3c27$0$30019$4f793bc4@news.tdc.fi> Organization: TDC Internet Services NNTP-Posting-Host: 81.17.205.61 X-Trace: 1236941863 news.tdc.fi 30019 81.17.205.61:33105 X-Complaints-To: abuse@tdcnet.fi Xref: g2news2.google.com comp.lang.ada:5073 Date: 2009-03-13T12:58:05+02:00 List-Id: Jarno wrote: > Niklas Holsti: > >> An interface type that defines the common view of "Points" of >> whatever representation? That would allow non-hierarchical and >> independent implementations of the representations as long as >> every representation implements this interface. > > Can you please post a simple example? Does interface means > extendable type (�interface� or �tagged�)? Yes, I meant types that extend (implement) an interface type. I had in fact missed that your original posting did not make these "Point" types tagged, that is, you did not ask about a *type* hierarchy but only about a *package* hierarchy. This being the case, I don't see enough information in your original posting to answer your question. If these types have nothing else in common but their use to represent 2D or 3D points, and the existence of conversions between them, there is little basis for evaluating your alternatives. The only reason for using child packages would be to organize your package names hierarchically, which is of course nice but introduces unnecessary compilation dependencies, especially if you declare the "preferable representation" in the common parent package. So that much can be answered: to minimize compilation dependencies, parent packages should contain only stuff that is common (in some sense) to all children. You also said: > .. it is desirable for representations to be generic. By "generic", do you mean that you will have generic units that take a formal type parameter to specify which "Point" representation they use? Such as: generic type Point_Type is private; procedure Rotate_Figure ... If so, you must ensure that the various kinds of "Point" all implement compatible operations, to be associated with the in the generic instances. If you use a tagged type hierarchy or an interface type, operations like Rotate_Figure can be class-wide, rather than generic, or can avoid the declaration of by using instead the primitive operations of the formal type parameter. > Seems that I need to organize a bunch of generic > interconvertible types and still be able to add other > representations later with minimal cost. Do you need conversion from any "point" type to any other "point" type? That would be a quadratic number of conversions, which is to be avoided, of course. If all "point" types implement a common interface, you could write a single "constructor" function for each "point" type, say PT, that creates an object of type PT from any parameter that implements this interface. This single function can then be used to convert any other "point" object to an object of type PT. There may be a small decrease in floating-point numerical accuracy in this approach, because it is like first converting the source type to a "preferable" type (the interface), and then from there to the target type, with round-offs in both conversions. > I think run-time dispatching would be too much heavy. Using tagged types or interfaces has two penalties: extra space in each object to store the tag, and extra execution time *if* run-time dispatching is used. But I sense that you want to have different "point" representations because you want to use the most suitable representation for each algorithm. If you write your algorithms as type-specific rather class-wide, the compiler should bind all operations statically, even if the types are tagged. The need to assign and copy tags implies a (small) time penalty even if operations are statically bound. If this is important to you, or if the space overhead of tags is important, I would recommend a two-layer approach: define the various "Point" types as untagged, and then define a "wrapping" tagged type hierarchy (or interface-implementing types) that has some such untagged "Point" type as a component. You can then write your type-specific algorithms using the untagged types, and "wrap" them into objects of the tagged type(s) when you want to be class-wide. For example: -- The untagged representations: type Cartesian_Point is record .. end record; type Spherical_Point is record .. end record; -- The tagged representations: type Tagged_Point is abstract tagged null record; type Tagged_Cartesian_Point is new Tagged_Point with record Point : Cartesian_Point; end record; type Spherical_Cartesian_Point is new Tagged_Point with record Point : Spherical_Point; end record; -- The algorithms: procedure Cartesian_Algo (P : Cartesian_Point) is ... procedure Spherical_Algo (P : Spherical_Point) is ... procedure Class_Wide_Algo (P : Tagged_Point'Class) is ... HTH, -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .