Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management

["Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com>]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> 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/.