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,772ae8afc5db35f2 X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: Can't export object of private type Date: 1999/03/10 Message-ID: #1/1 X-Deja-AN: 453308360 Sender: matt@mheaney.ni.net References: NNTP-Posting-Date: Wed, 10 Mar 1999 00:13:07 PDT Newsgroups: comp.lang.ada Date: 1999-03-10T00:00:00+00:00 List-Id: nospam@thanks.com.au (Don Harrison) writes: > :You can't enforce this using the type system. > > I'm beginning to believe that. :( The language can't do everything for you. If you declare a type like this: package P is type T (<>) is limited private; end P; then there's nothing in the language that forces you to implement a constructor for the type. This type is useless without a constructor, but Ada can only prevent you from doing harmful things, not useless things. And besides, you don't need the language to tell you, because human programmers who try to use your type will tell you right away! > :This is like declaring a type, and then trying to have an operation that > :forces clients to declare instances of the type. Huh??? > > Not at all. It's nothing like that. The nature of the inheritance relation > is completely different from the client relation. Whereas a client should > *optionally* use a supplier (including declaring instances of it), a > derivation should be *forced* to honour its parent's contract; otherwise, > polymorphism breaks. I see it exactly the opposite. Construction is part of the relationship between client and specific type, not part of the inheritance relation. Different clients have different construction needs, and every client might very well declare his own custom constructor for the type. This is the great thing about child units: package P is type T (<>) is limited private; ... function Default_Constructor return T_Access; end P; Let's say I have very specific construction needs, and Default_Constructor isn't adequate. For ex, I might need to stream the object in off of disk. So I just declare my own constructor: function P.My_Constructor (Filename : String) return T_Access; One of the purposes of the child facility is to allow you to efficiently extend an abstraction. Note that this kind of "extension" doesn't extend the type in the same sense as deriving from a tagged type. We are not creating a new type. Here, we want only to add a non-primitive operation to the type --a constructor-- that has the same efficiency and convenience of primitive operations.