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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: about inheritance of subtypes and entities (such as constants) related to a type in the same package Date: Fri, 1 Jun 2018 09:35:07 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <33e69ed1-d4ba-4fd9-9d82-5b7cb1971596@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:52834 Date: 2018-06-01T09:35:07+02:00 List-Id: On 2018-06-01 01:39 AM, Mehdi Saada wrote: > The idea was to define for a given (private) type, a series of subtypes with different type invariant, or with or without unknown discriminants (the box), to provide specific variant of the same ADT. OK, this is a set of related types (though Ada pundits would claim that subtype is not a type). > I know now that is meant to be done through tagged types, and that subtypes are no good for that. No, you cannot do that with tagged types. These are two different type-algebraic operations: 1. subtype creates a new subtype by constraining the base 2. tagged extension creates a new "subtype" by using a set product over the original values set None substitutes another, but you can mix them. They are fully orthogonal. > But I would have liked a mechanism to generate, why deriving a new type from a parent, these tailored subtypes, with the same same, just like they would have been rewritten. Deriving creates a new type in a class of types. When you create an Ada subtype it is a new member of the class rooted in the base type. When you derive from a tagged type T you add a new member to the class rooted in T. What you want is to copy a whole class. It is a second order type operation. Ada has two means for that: 1. Type cloning: type X is new Y; This does not work for tagged types and it does not clone subtypes. 2. Generic instantiation. This works for anything, but imposes severe software design problems. > But it doesn't take much to see it wasn't a good idea, and that a lot problem would occur... like: what happens when the derived type has constraints or invariants incompatible with subtypes associated with the parent ? That cannot happen because constraints are inherited. If you need another constraint you derive another type. > I should say "Copying" rather than inheriting. "Copying" constants would fail for the same reason. I/one is better of with converting the constants defined once, for the whole type hierarchy. Though the problem is only with untagged types, tagged private types have class-wide constants. Both mechanisms copy literals if that is what you meant. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de