Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!DATJN@NEUVM1.Bitnet
From: DATJN@NEUVM1.Bitnet (Jakob Nielsen Tech Univ of Denmark)
Newsgroups: comp.sys.mac.hypercard
Subject: Computer Science analysis of HyperTalk wanted
Message-ID: <50156@sun.uucp>
Date: 20 Apr 88 15:46:26 GMT
Sender: news@sun.uucp
Distribution: comp
Lines: 30
Approved: hyper-hackers%plaid@sun.com

Has anybody written an analysis of HyperTalk from a traditional
computer science language perspective ?
Some observations of my own:

In the April 1988 APDAlog Newsletter, Dan Shafer recommends the
following script to manage radio buttons:
 on mouseUp
   set the hilite of me to true
   repeat with counter = 8 to 15
     if counter is not the number of me then set the hilite of -
     button counter to false
   end repeat
 end mouseUp

Note that this code will fail under the following condition (among
many other possibilities):
If I have *two* set of radio buttons of this kind and remove a button
from the bottommost set, then the numbers of the buttons in the
topmost set will all be diminished by one - instant bug!
So this coding style which is encouraged by the design of HyperCard is
definitively *not* modular.
One of the problems is that something which can be considered part of
the state of an object (its number) is modified when changing other objects.

Another case:
When linking a button to a card, HyperCard changes the script of the
button to include the number of the card being linked to.
Modifying code instead of variables ... Here the destination information
is hardwired into the code instead of being kept in a local variable
of the button.