"Alan Gauld" <alan.gauld at bt.com> wrote in message
news:3AD5C725.33693D16 at bt.com...
[snip]
> > for the next one -- that (in my experience) makes event-driven
> > processing nowhere as hard to learn, master _and_ use productively
> > as interrupt-driven programming
>
> Yes, but if you know interrupt programming - as an assembler
> programmer might - then event driven is a piece of cake once you
> realize its the same conceptual model :-)
True -- if you know how to handle a harder problem, realizing
that an easier one falls into similar patterns helps a lot.
> > you are still thinking about ONE path
> > of execution, albeit split up into not-too-big chunks.
>
> Only within an event handler, the flow of control across
> a use-case say is still fragmented and several use-cases
> may be executing simultaneously. Thus all of the context
> saving issues still apply - and for that OO makes it sooooo
> much easier :-)
An excellent point about "granularity" in use-case terms.
And, yes, natural places for stashing all of the state away
do come in handy indeed.
Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4