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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c08a7609345f4e5 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Limited use for limited with? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <853314bc-0f79-435f-86a5-d7bcdd610731@c10g2000yqh.googlegroups.com> <36e886fa-b272-461f-bf86-a6b18366b64f@i5g2000yqe.googlegroups.com> <1eug9v5h5mf8d$.ud00hrz48lyr.dlg@40tude.net> <67044906-dacc-4526-b3f6-27e5323ab8fc@n3g2000yqb.googlegroups.com> <12chb4kbqt9ln$.zumsv1z9hqvk$.dlg@40tude.net> <292dd0bd-1fc4-4715-bb70-7655d0dc04eb@j24g2000yqa.googlegroups.com> <1ffdzc3fkapks$.15g452pvvgrem$.dlg@40tude.net> Date: Wed, 29 Sep 2010 23:18:28 +0200 Message-ID: <15ugvogl5r3li$.1u085y9xge6ft.dlg@40tude.net> NNTP-Posting-Date: 29 Sep 2010 23:18:26 CEST NNTP-Posting-Host: a5eac18f.newsspool3.arcor-online.net X-Trace: DXC=lVHZ[:RQMcF=Q^Z^V3X4Fo<]lROoRQ8kFT\^nE^;mY[6LHn;2LCV^[W6XjG5\ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14320 Date: 2010-09-29T23:18:26+02:00 List-Id: On Wed, 29 Sep 2010 13:51:53 -0700 (PDT), Maciej Sobczak wrote: > On 29 Wrz, 15:41, "Dmitry A. Kazakov" > wrote: > >>> This would create circular dependency between Object and Registry's >>> internals. >> >> You add one derived type to either of the hierarchies and that breaks the >> dependency. You have to with or without access types. > > Not at all. In my design Object knows nothing about registry. There is > no such dependency and therefore it does not have to be broken. > You have introduced this dependency, but this is one of the many > reasons why I don't like your solution. I did not. You have to pass an object or its pointer to the registry, or a registry to the object. It is no matter, the operation has two arguments. The dependency is here. >> Object would call a class-wide operation of Registry from its Finalize. > > This assumes that Registry is object-oriented and that all registries > have some common interface. I don't want this assumption, it does not > reflect any system requirement. It is not an assumption. All registries are capable to maintain objects. The set of registry types shares this property, even if you don't introduce this set as a class, which would be an unwise decision, the class is here. >>> I don't control the concrete >>> implementation - in particular I don't implement the factory >>> (constructor function). >> >> You declare the factory function abstract to be implemented by derived >> types. > > And how can I enforce that user will properly use the registry from > the constructor? By hiding other ways to construct the parent type. If the object is declared with (<>) discriminants and its full view is hidden you have to use the construction function in the aggregate that creates the object. >>> The solution that you propose is not only very complex, >> >> I don't see how removing a type could add complexity. > > In order to "remove a type" you have introduced: > - factory functions, perhaps abstract I don't expose object components anyway. It is a good style to have components private. If Initialize does not do the job, factory function is the only choice, because, unfortunately, Ada does not have proper constructors with parameters. > - Controlled with Finalized Same as above. Non-controlled tagged types make no sense, because, again, Ada lacks constructors and destructors. > - circular dependencies between Object and Registry (ironically, you > have then proposed to introduce *another derived type* to break that > dependency - does it still count as "removing a type"?) The dependency exists anyway. [ And it is not circular. The relation "there exists an operation with arguments of both types" is symmetric. ] > - common tagged root for all registries (this seems to be also an > additional type) A big advantage, because later I might wish to write some class-wide operations dealing with any registry. It happened to me so many times, that I practically always use controlled bases. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de