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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e1bb9627c57b7d5b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-09 01:32:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!NewsITBone-GARR!area.cu.mi.it!newsfeeder.edisontel.com!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...) Date: Thu, 09 Oct 2003 10:42:05 +0200 Message-ID: <8i6aov011dia1vsiv3ihsh1kvmul5nlesk@4ax.com> References: <86u4ov4ojmuugvp2p4qsg725ah45p01c2h@4ax.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1065688357 18688527 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:522 Date: 2003-10-09T10:42:05+02:00 List-Id: On Wed, 8 Oct 2003 23:12:35 +0400 (MSD), "Alexandre E. Kopilovitch" wrote: >Dmitry A. Kazakov wrote: > >> > type Y is private envelope of X; >> > >> [...] >> >> Looks similar to my proposal for defining subtypes. > >I think yes, there is much in common, although there is also a difference: >your proposal is significantly broader; it is certainly heavier as it pertains >to possible consequences, and I have no immediate opinion whether it will be >easier to find sound applications for that your proposal than for mine, more >narrow one. Yes. I wish Ada's ADT be fully reviewed. Yet, I believe, that it can remain compatibile to Ada 83. >> Why to call "envelope" something which is a subtype? (:-)) > >"subtype" in Ada implies a possibility of some kind of restriction imposed on >the base type, while the word "envelope" implies some kind of extension (of >functionality or applicability). You see, for a language terms I strongly >prefer application/user view to a compilation theory's view, even for advanced >entities/constructions. This is the crucial point. Subtype should imply nothing, but substitutability, in the sense that you can pass objects of the subtype where the base type is expected. The rest is implementation details. A subtype can be made either by a specialization (like constraining) or a generalization (like type extension) or by providing a completely new implementation (interface inheritance from a non-abstract type). But all these ways are no more than implementation details which could be moved to the private part. >> It should be something like: >> >> type Y is private subtype X; >> >> Note that for the sake of genericity one need more than two >> conversions. There should be four: >> >> X_From_Y, X_To_Y - this pair is used when an Y gets substituted for X, >> i.e. when Y *inherits* a subprogram from X. One of these conversions >> might be absent. Then Y becomes an in-subtype or an out-subtype of X: >> >> type Y is private in subtype X; >> -- Only in-subroutines are inherited. So only X_From_Y has to be >> -- defined >> >> Y_From_X, Y_To_X - this pair is used when X gets substituted for Y, >> i.e. when Y exports something to X. This is a way to create >> supertypes. >> >> type Y is private in out supertype X: > >Well, it seems that your proposal uses basic diagrams while mine is restricted >to isomorphic representations. You are poisoned by LSP! (:-)) >> If all four conversions are present both types become fully >> interchangeable, which is actually required in case String vs. >> Unbounded_String. > >I don't see why two conversions (which provide isomorhic representation) >aren't enough for String vs. Unbounded_String... if we have no intention to >extend current functionality (except of making implicit conversions possible). Because, I do not want isomorhic representations. I want a fundamentally new, universal concept of subtyping which would cover all known cases. For instance, it would work for tagged extensible types. If the subtype just extends the base (contains it representation), then the pair of conversions Base_*_Derived are just view conversions, because Derived has an instance of Base. Another pair Derived_*_Base should create and destroy a completely new Derived object. Presently the second pair is outlawed in Ada, so we have only view conversions from Derived to Base (forth and back). This limits use of tagged types. For example, they cannot be directly used to implement multiple representations, I mean the cases when Derived has to be an equivalent [sub- and supertype] of Base, and not just a subtype. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de