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!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Generic Embedded List Nodes Date: Tue, 21 Jun 2016 21:54:18 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <66c14298-c62d-4f4b-b0c0-e969454f9334@googlegroups.com> <2e39857a-7121-476b-807a-d2bff1e598f4@googlegroups.com> <431af616-7df3-4e4d-9262-26ed68cb74c7@googlegroups.com> <037df2b8-b9c4-4447-87ee-cc89d7072b30@googlegroups.com> <15914c54-191c-4f37-b754-282855d1aeaf@googlegroups.com> <3e25c9a0-469c-4487-b78e-6f87434f87fa@googlegroups.com> <2e69ca6f-484c-4d58-b0fe-d17a744b1418@googlegroups.com> NNTP-Posting-Host: w/2xSGckQeJEFvqsQFNodA.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:45.0) Gecko/20100101 Thunderbird/45.1.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:30862 Date: 2016-06-21T21:54:18+02:00 List-Id: On 2016-06-21 20:54, Niklas Holsti wrote: > On 16-06-21 10:15 , Dmitry A. Kazakov wrote: >> On 21/06/2016 07:52, Niklas Holsti wrote: >> >>> If you don't get the address arithmetic to work, >> >> There is a subtle difference between access and X'Address, but otherwise >> address arithmetic works. E.g. I can instantiate my implementation of >> linked lists with any type including unconstrained and non-tagged ones. >> >>> I believe that a set of >>> mixin-generics could be used to add as many embedded Emb_Nodes to a >>> tagged limited record, with access discriminants pointing to the >>> containing record. >> >> Adding links afterwards is even worse than deriving objects from a >> abstract list node. > > Why do you think so? For philosophical or practical reasons? Practical reasons. If you derive from the list element base you cannot have scalar or other non-tagged objects as elements, but you still can have a class of elements. When you add links last, you cannot have a class, that in effect finalizes the list item. > But your pool-based design restricts objects to be linked into at most > one list. The OP said that an object can be placed in two or more lists > at the same time, and apparently the number of such lists varies > according to the type of the object, depending on the number of embedded > list nodes within the object. > > The pool-based design can no doubt be extended to allow multiple lists, > but it then becomes more complex. It is no more complex. In fact my design is multiple lists from the start. Doubly-linked list is a specialization of. BTW, a design based on inheritance requires multiple additive inheritance for lists. Ada does not have this even for interfaces. E.g. type Abstract_List_Item is abstract tagged record Next : not null access Abstract_List_Item'Class := Abstract_List_Item'Access; Previous : not null access Abstract_List_Item'Class := Abstract_List_Item'Access; end record; type My_List_Item is -- This is not Ada! new Abstract_List_Item as List_One or Abstract_List_Item as List_Two with record X : Integer; end record; Members and primitive operations are renamed to resolve name clashes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de