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: 108717,c1d77749223627c8 X-Google-Thread: 1108a1,8802fe2212b159e1 X-Google-Thread: 114809,8802fe2212b159e1 X-Google-Thread: 103376,6cd90863b65ff36b X-Google-Attributes: gid108717,gid1108a1,gid114809,gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny06.POSTED!ab059812!not-for-mail From: "Thomas G. Marshall" Newsgroups: comp.programming,comp.object,comp.lang.smalltalk,comp.lang.ada References: <40f3ceee@alpha.wvnet.edu> <19iip59qsl122$.3g3hicltra17.dlg@40tude.net> <40f5bbe1@alpha.wvnet.edu> <40f67c13@alpha.wvnet.edu> <9qTRc.61502$M95.25853@pd7tw1no> <411C5D2F.5070408@acm.org> <3bOUc.46253$US4.14922@trndny01> <40cmn8qnj5kv$.1llvajtdbf755.dlg@40tude.net> Subject: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: Date: Thu, 19 Aug 2004 16:24:05 GMT NNTP-Posting-Host: 151.203.224.68 X-Complaints-To: abuse@verizon.net X-Trace: trndny06 1092932645 151.203.224.68 (Thu, 19 Aug 2004 12:24:05 EDT) NNTP-Posting-Date: Thu, 19 Aug 2004 12:24:05 EDT Xref: g2news1.google.com comp.programming:8434 comp.object:5849 comp.lang.smalltalk:2569 comp.lang.ada:2859 Date: 2004-08-19T16:24:05+00:00 List-Id: Dmitry A. Kazakov coughed up the following: > On Thu, 19 Aug 2004 04:54:42 GMT, Thomas G. Marshall wrote: > >> Without having to hand you an inch thick spec......ok. Here: >> >> Think java applet running on a pc. That pc connected to a very >> complicated scientific device, composed of a great many number >> producing things. I'm going to use the term "gui component" here, >> but I really mean more than View, but also the Model/Controller >> folded in as well. >> >> One of my java clients needed a very complicated multi-layered gui, >> where each of the visual components (meters, text fields, flashing >> lights, text labels grayed out, red, or red/gray, or blinking), had >> to in real time reflect what was happening to that component's >> counterpart within another device. >> >> A ton of meterable "things" in the device, and a ton of real time gui >> elements in the java app reflecting the various values, states, >> warning levels, what have you. Many of the gui items further >> controlled other "things" in the device, which caused only a cascade >> of changes in the gui elements that were monitoring the components >> from the device. >> >> For a huge part of the development, the gui components were designed >> around their own threads. One drawn LED that needed to be updated 5 >> times a second, one thread. A textfield next to it that needed to >> be updated 25 times a second, another thread. Each of those threads >> ran in real time collecting (and sometimes sending) to/from the >> device. >> >> When the number of such continually active gui components threatened >> to exceed several hundred, we shifted the model and from the top >> converted every single component into an entry into something called >> the Dispatch. Dispatch maintained a list(1) of lists(2) of >> components. Each list(2) was a list of components that needed >> updating a particular interval. All the 50ms updates went into one >> such list. All slower 150ms updates went into another, etc. 23 >> distinct interval types meant 23 entries in list(1), each of which a >> list(2) of components. >> >> Because it was done in Java, a statically typed language, there was >> a great deal of energy spent in just turning the crank of making >> sure that the types shifted from prior strategy to the current one. >> I hope I've been clear enough here. > > 1. I would say that it was a design fault. The idea to use active > objects > for GUI instruments is wrong. We used to design several similar > projects > and never tried to go that way, because it is so obviously(?) wrong. Stay off your high horse. > GUI instruments should be passive controlled by "referesh" threads > from > outside. They were. Actually, that's not "passive", that's /actively/ controlled and controlling, because many of the gui elements were dual duty: they move as accessors, but can be moved (by user) to mutate. > Also that they should not directly communicate with neither > actors nor sensors (devices), but do it through a middleware > interface. We did that too. From the beginning. When I'm refering to gui components, I'm refering to /all/ that it takes for the gui component to work. Remember, this has to be a quick sketch of what was going on. ...[rip]... -- http://www.allexperts.com is a nifty way to get an answer to just about /anything/.