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: a07f3367d7,c08a7609345f4e5 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 13 Oct 2010 10:44:06 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101004 Thunderbird/3.1.5 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Limited use for limited with? 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> <09c36bd6-edfa-42bf-8f33-e91b0a9b0737@26g2000yqv.googlegroups.com> <1f38791b-a579-49ed-839c-e6ff3867de76@30g2000yqm.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4cb57156$0$7654$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 13 Oct 2010 10:44:06 CEST NNTP-Posting-Host: 9d061c2b.newsspool1.arcor-online.net X-Trace: DXC=AP0<>A?>aPT\9P[:DUn00Qic==]BZ:af^4Fo<]lROoRQ<`=YMgDjhgR9hGMMZkPF?VBhmZ On 10/13/10 4:09 AM, Randy Brukardt wrote: > "Maciej Sobczak" wrote in message >> But it is not applicable in general. Think about how messed up it >> would become for N:M case (each job delivered to potentially many >> tasks). > > N:M would be what I called chaos at the start of this thread! There has to > be some structure to the events or you really do have chaos. So you have to > partition that into a set of events that all go to a single object/task, and > broadcast events that each go to a set of objects/tasks. That is, the > program is a bunch of 1:N and N:1 events, and they don't (directly) > interact. The design seems to assume one program of unchanging object structure once it has been output by the compiler. After that, it is known to be organized such and such, known to the one instance of program integration. Some organizational unit is aware of its total design. Assume instead a program composed of parts such that organizational boundaries will prevent knowing the total design, in every detail. For example, it is not known what exactly N and M will be (for N:M or even N:1). The system has a changing number of superior objects (agents, triggering events) and inferior objects (handling events). Software companies write components, other software companies compose programs from the components. Engineers add and remove components, during system operation if possible. But no one knows beforehand the set of events, or the set of handlers. Typical Superiors might be called The_Mechanical_Seargant, Task_Queue, Central_Services, Boss_Miller, The_President, Radar, or Klaxon. Inferiors are identified by Worker, Mr_Hill, Valve, Sink, or Magic_Apparatus. There may one or many of each of those, their number can change, and they may be turned on or off. That is N(t):M(t), t in Time. For example, Worker(13) might be busy and thus is unavailable for handing any event. Boss_Miller might be off. The_President might visit the site and trigger an unforeseen event, no matter what. Broadcast then really means broadcast: just any event handler can pick an event and react as programmed. Or not. But the programmers who wrote the handlers had not known about the totality (there you have another "ility" ;-) of circumstances of events, or their origin, or their specific type. Neither did the system makers foresee all circumstances triggering an event, or handlers available. Neither party may be able to predict all additions of events or handlers to some partition, or their removal, or malfunctioning. Is it realistic to assume that such a large, multi-organization, changing system can be modeled with "known specific handler" in mind? Without pointers, but scope based? (And isn't something like Linda tuple spaces, IIRC, directly opposed to scope based and deterministic solutions?) Georg