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-Thread: 103376,a8d137db7a5f6c81 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: OO problem: Performing actions on messages (very long, sorry) Date: Wed, 5 Jan 2005 21:44:31 +0100 Organization: cbb software GmbH Message-ID: <1rall0nftkcsj$.1e5jj6uwwwezc.dlg@40tude.net> References: <1103723394.299024.314670@c13g2000cwb.googlegroups.com> <13465377.hrn0RlrJV7@linux1.krischik.com> <1103737351.196460.85450@f14g2000cwb.googlegroups.com> <1qdvdjid4u58v.1xz6j5ec6nfcy$.dlg@40tude.net> <1104755823.837077.74630@z14g2000cwz.googlegroups.com> <8oknh024yb43$.71qlyp6g8y2x$.dlg@40tude.net> <1104840326.160879.132400@c13g2000cwb.googlegroups.com> <1ogeykubpns90.2jnblmdu1wg2.dlg@40tude.net> <1104852099.054703.265080@f14g2000cwb.googlegroups.com> <1104926478.797780.7830@c13g2000cwb.googlegroups.com> <1odpvi9429wrb.r854wtzbr1qm$.dlg@40tude.net> <1104940745.420814.235130@f14g2000cwb.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net KRHsIalwpeslQI/5NeEtwgPXi+dUUtROXL2cnfT7cR8g600wU= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7490 Date: 2005-01-05T21:44:31+01:00 List-Id: On 5 Jan 2005 07:59:05 -0800, per wrote: >>OK, I see. But then the question to answer what purpose serves message >>apart from being just a container for unrelated data? The difficulties of >>the design come from that missing pupose. If there is nothing in common >>then nothing can be programmed for that nothing. (:-)) > > Well, each message *is* a simple container, more or less. The contents > are related in the sense they are to be sent to/from a certain device > that expects a defined set of information. The program we discuss > doesn't really care at all of the contents of each message, but shall > provide means to the user to override any message content (among other > things). How do you plan to maintain data consistency of a message if the user may arbitrarily override its fields? I would try to do it more OO. To think about what can be done with a message. And consider action as an implementation detail of a concrete type of messages. Then actions could vanish. (Just a guess, I still can't tolerate both messages and actions in one bottle. (:-)) >>Hmm, what about this mix-in: >> >>package Interfaces is >> type Message is abstract tagged ... >> type Action is abstract tagged limited ...; >> procedure Execute (This : in out Action) is abstract; >>end Interfaces; >> >>package M1_Thinds is >> type M1 is new Message with record -- Message M1 >> A : Integer; >> B : Float; >> end record; >> >> type M1_Action (Data : access M1) is -- Abstract actions on M1 >> abstract new Action with null record; >> >> type Override_A is new M1_Action with record >> A : Integer; >> end record; >> procedure Execute (This : in out Override_A); >> >> type Override_B is new M1_Action with record >> B : Float; >> end record; >> procedure Execute (This : in out Override_B); >> ... >> >>package body M1_Things >> procedure Execute (This : in out Override_A) is >> begin >> This.Data.A := This.A; >> end Execute; >> >> procedure Execute (This : in out Override_B) is >> begin >> This.Data.B := This.B; >> end Execute; >> >>Here all actions on some type of messages have a "pointer" to the >>corresponding message object. The scope of an action should be nested in >>the scope of the message. >> >>Here in fact action is a pointer to message extended with some additional >>data. When scopes get different, then action could be a handle to message. >>Messages will be collected using reference counting. > > I kind of see what this aims at (although "mix-in" is new to me). > > As far as I see we're back to defining one action type for each message > and each field in the message, although this time without the generics, > right? Yes, generics do not help here much because the field name cannot be a formal parameter. > Can an action, eg Override_A, exist without an M1 instance to "point" > at? It cannot, this is the whole idea of access discriminants. They are never null and cannot be changed. Otherwise one should use access types (pointers). > Action has a different life-cycle than Message. That's no problem as long as its life in Message's one. For exampe: declare M : aliased M1; begin ... declare A : Override_A (M'Access); begin ... -- The scope of the action A is nested end; ... end; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de