The RR programming model [pretty lengthy]

[Jan Schenkel]

--- Simon Forster <simon-lists at ldml.com> wrote:
> 
> [snip]
> 
> Seriously, can someone put the whole stack thing
> into some sort of 
> perspective wrt more traditional programming
> languages - or point me to 
> a resource which does this? I think it'd help me
> quite a lot.
> 
> TIA
> 
> Simon Forster
> 

Hi Simon,

I'm sure there are lots of resources out there, a
number of which will probably give you a better
explanation, but I'll give it a shot nonetheless.

In the old days of procedural programming, the
application pretty much decided where the user was
going to go next.
As in: the user has a limited set of choices, and he
types 1,2,3 or Q and my program reacts to this input.
I control what the user can type.

Then came the Graphical User Interface and all of a
sudden the paradigm shifted: the user was in control
now, and could jump from place to place and do things
in a sequence trhat we didn't quite have in mind.
As in: the user may decide to fill in field 5, then
field 6, click on a button here, or even attempt to
select a menu or dismiss my screen to the background.

So programs changed and sat in a (foundation) loop,
responding to the events the user's actions generated,
enabling and disabling options, and when the user
pressed some button, run a procedure.
As in: an event loop capturing the messages, trying to
figure out what window is active and call the correct
procedure in response to the action.

Along with the GUI another idea became a hot topic:
object-oriented programming and its reuse of standard
components.
The GUI was an excellent candidate for this sort of
technology, as you could write special-purpose
controls that would respond ion a consistent way.
A lot of 'traditional' programming languages
incorporated class libraries and some even adopted the
Integrated Development Environment, where you could
design screens and such niceties.
As in: Think Class Library, MacApp, Turbo Pascal /
Borland Delphi, and more recently Java.

Before OOP seriously took off, several graphical
programming environments came up, taking care of the
event loop and calling the procedures for you.
All the programmer had to do was design the screen and
code the procedures behind every control to particular
actions.
The programming languages themselves are 'fourth
generation' and are usually much closer to human
languages (often English).
Their constructs for loops and branches are also much
easier to read by non-programmers.
Prime examples: HyperCard in 1987, Visual Basic a
number of years later.

These graphical programming environments often adopted
techniques from OOP, though sometimes only partially
or with clear restrictions.
The 'xCard' approach adopted the 'message hierarchy'
that's present in most class libraries: an event is
handled at the front, or sent 'up the command chain'.

In the Think Class Library for example, 'panes' handle
things at the front, or send the message up to the
'document' to which they belong which in turn may send
it up to the 'application' itself.
If you wanted, you could adapt the chain, inserting
layers or even have multiple chains.

In HyperCard, the following layers were introduced:

       button / field
       --------------
            card
       --------------
         background
       --------------
            stack
       --------------
        'home' stack
       --------------
          HyperCard

Though the above representation cheerfully avoids the
difference between card and background buttons and
fields, it describes the 'message chain' adequately.
Example:
- when a user clicks on a button, a 'mouseUp' message
is sent to the button
- if the button doesn't handle it, the 'mouseUp'
message is sent up the chain to the card
- if the card doesn't handle it, the 'mouseUp' message
is sent up the chain to the background
- if the background doesn't handle it, the 'mouseUp'
message is sent up the chain to the stack
- if the stack doesn't handle it, the 'mouseUp'
message is sent up the chain to the home stack
- if HyperCard doesn't have a default associated
behaviour, the message is simply discarded and nothing
happens.

But the xCard implementation of the message chain
doesn't stop there: besides a number of standard
'events' it also employs user-defined 'handlers' and
'functions'.
These procedures (as that's what they basically are)
are also part of the chain, allowing a procedure to
call another procedure that is defined at the same
level or higher up in the chain.

In this way, xCard brought in some aspects of OOP, but
limiting them at the same time: there is no 'true'
inheritance, and the message hierarchy is 'fixed'.
The original hierarchy has been adapted along the
road, but there's an excellent chapter in the
documentation that gives you all the details you may
ever want to know about the message path.

So there you have it: scripts in objects handle
messages, which travel along a message path.

Hope this helped clear a few things up,

Jan Schenkel.

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com