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!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada Successor Language Date: Mon, 25 Jun 2018 23:52:20 +0300 Organization: Tidorum Ltd Message-ID: References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> <878t7u1cfm.fsf@nightsong.com> <776f3645-ed0c-4118-9b4d-21660e3bba4b@googlegroups.com> <87602fbu2g.fsf@nightsong.com> <87po0mziqt.fsf@nightsong.com> <87fu1izfgs.fsf@nightsong.com> <878t75nwad.fsf@adaheads.home> <4bdf7c54-e7e9-427a-ad69-149f10ba1fb3@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net UaIdq3eiNnUm88LysaJSzwiP+Se9uCiTbym7Z3IJKDlJ7A+y4b Cancel-Lock: sha1:kq0tUGgI5GYQkwKloFikhRFZ5yg= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <4bdf7c54-e7e9-427a-ad69-149f10ba1fb3@googlegroups.com> Xref: reader02.eternal-september.org comp.lang.ada:53314 Date: 2018-06-25T23:52:20+03:00 List-Id: On 18-06-25 23:13 , Dan'l Miller wrote: > On Monday, June 25, 2018 at 2:16:36 PM UTC-5, Niklas Holsti wrote: >> On 18-06-25 17:21 , Dmitry A. Kazakov wrote: >>> On 2018-06-25 16:03, Niklas Holsti wrote: >>> >>>> (In fact, it seems to me that Ada could allow untagged record >>>> extensions as well; the effect would be the same as for tagged >>>> ones, but no 'Class would be formed, and no class-wide >>>> programming or dynamic dispatch could be used, so all such >>>> types would be static. >>> >>> Ada could allow T'Class for untagged T. T'Class would be an >>> indefinite type with values consisting of the actual type's tag >>> and its value. When T is by-value type, you pass T'Class to a >>> subprogram as tag + value. When T is by-reference type, you pass >>> tag + reference. >> >> Yes, that could be another point in the division of the "OO >> programming concept" into smaller, more "primitive" features -- >> building blocks -- which could be combined in various ways. >> >> Your suggestion would allow class-wide programming without storing >> tags _in_ objects. > > The programmer promising to correctly store the right tag outside of > objects would be a new level of human achievement in defeating strong > typing. No, there would be no manual tag manipulation. The compiler would automatically pass the tag value when needed, that is, when a call associates an object/expression of a statically known specific type S with a formal parameter of the type (some ancestor of S)'Class. The compiler would construct the tag values for an untagged type derivation tree just as for tagged types, but would not store the tag values in objects. Passing the tag separately, as part of a parameter of type T'Class, is similar to passing separately the actual bounds of a formal parameter of an unconstrained array type. > * i.e., what syntax? Same syntax as now: specific types T (whether tagged or untagged) and class-wide types T'Class. But, as Dmitry said, re-dispatch for untagged T'Class would not be possible, because only objects of class-wide types would carry tags. Objects (and views) of specific types would not carry tags at run time; the compiler would know the tag value for each such object and use it when an object of a specific type is converted to a class-wide type for passing to a class-wide operation. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .