"Chris Malcolm" > wrote in message
...
> In alt.support.diabetes Ellen K. >
> wrote:
>
>> "Chris Malcolm" > wrote in message
>> ...
>>> In alt.support.diabetes RodS > wrote:
>>>> On 18/09/2010 5:14 AM, Boomer wrote:
>>>
>>>>> Interesting to find out how much so many of us have in common besides
>>>>> diabetes. Code writing is becoming something now that many employees
>>>>> simply must do. Learn how or perish. I think you spent much more time
>>>>> at
>>>>> this than I have. Like I said I had this fault of creating nested if
>>>>> thens that would make my head explode.
>>>
>>>> Easy just bung in a goto instead :-)
>>>> or better yet nested gotos :-)
>>>
>>>>> I did solve a lot of these with
>>>>> the switch command. Solve is not the right answer, made better would
>>>>> be
>>>>> more accurate.
>>>
>>> Having to have a lot of complex exceptions to the main line of
>>> structured code is often a sign that you're trying to do the right
>>> thing, which is to follow the logic of the data structures with the
>>> procedural or subroutine delegation of the program code, but
>>> something's gone wrong. That data strucure following works very well
>>> when the data structure is categorically well structure. It fails when
>>> you have to deal with two parallel or independent kinds of data
>>> structures. In that case whichever data structure you follow with your
>>> code, the other has be dealt with by a patchwork of messy exceptions.
>>>
>>> Unless instead of subroutines you use (tada!) coroutines -- a very
>>> useful software control structuring trick available to the systems
>>> assembler programmer, but rarely reflected into higher level
>>> programming languages. It's a kind of simultaneous subroutine call and
>>> exit, which allows the co-existence of neatly programmed parallel
>>> control structures to follow parallel data structures.
>>>
>>> --
>>> Chris Malcolm
>
>> The situation you describe sounds like the very beginning of the process
>> needs to separately define the possible cases, then provide separate
>> handling for each one.
>
> The classic data structure problem which coroutines solve very neatly
> is the interleaved packaging problem which occurs in
> telecommunications. Suppose your comms protocol only allows maximum
> package sizes of 1 kilobyte at a time. So if you have lots of small
> emails to send then a dozen might be put into one package. So one
> package can will contain a number of emails. But if you have a large
> email of say 20 kilobytes to send, then your large email will contain
> lots of packages. So sometimes you have to unpack packages to get at
> the emails inside, and sometimes you have to unpack emails to get at
> the packages inside.
>
> That doesn't sound too hard a problem. But start adding in all sorts
> of exception conditions, retransmission requests, missing package
> problems, checksum failures at various levels, emails which contain
> attachments inside them, packages which are wrapped up inside larger
> transmission protocol packages, and it starts getting very messy.
>
> Hard to handle with classic data structures which insist on a simple
> categorical structures where for example emails must either be parts
> of a package, or alternatively packages must be parts of an email, but
> not both. The same goes for classic program control structuring
> methods such as procedural decomposition where control has the same
> strict hierarchy of delegatation and return of control. It would be
> like a management structure in which for some parts of the day your
> boss tells you what to do because he's your boss, and at other times
> you tell your boss what to do because you are his boss.
>
> --
> Chris Malcolm

I've never worked with that type of thing, only applications working
directly with business data, mostly financial.