Path: utzoo!attcan!uunet!tank!nic.MR.NET!hal!cwjcc!mailrus!purdue!decwrl!labrea!Portia!Jessica!duggie
From: duggie@Jessica.stanford.edu (Doug Felt)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: How can I get instance variables in buttons
Message-ID: <4089@Portia.Stanford.EDU>
Date: 11 Nov 88 18:08:27 GMT
References: <77053@sun.uucp>
Sender: news@Portia.Stanford.EDU
Reply-To: duggie@Jessica.stanford.edu (Doug Felt)
Distribution: comp
Organization: Stanford University
Lines: 52

In article <77053@sun.uucp> DATJN@NEUVM1.Bitnet (Jakob Nielsen Tech Univ of Denmark) writes:
>I would like to be able to associate values with buttons
>(e.g. a list of when it has been clicked, a pointer to a special
>card field which would be different for each button, a text string different
>from the name, etc.).
>
>As far as I can see, the only place I can put such info is in the button
>script [...]
> >Do anybody have ideas for a cleaner way to program this??

Alas, one of the consequences of Hypertalk not being a full
object-oriented language is the inability to create your own objects
with state.  Anyone who has tried to hack radio button groups will
understand this-- better still if they have tried to provide a 'tool'
for a naive user to create radio button groups.

One particular hack we have used (long ago, and I have since given up
scripting for writing XCMD's so we may have newer techniques) is to
store information in comment lines at the end of an object's script.
For instance, the last line of a radio button's script might look like
this:

     -- group 2

Other routines (in the background script) are used to facilitate
access to these 'variables'.  This, needless to say, is neither clean
nor fast.  Given the support routines to access and modify key/value
pairs, however, it is easy to code.  It might also be possible to
write code like this and then 'compile' it by stripping out variables
and the calls to access them and replacing them with new handlers to
get and set the globals.

At the last OOPSLA in San Diago a person from Apple demonstrated a
system for 'object-oriented' Hypertalk which 'compiled' descriptions
of methods and an inheritence hierarchy into the hypertalk handlers
needed to implement it.  Let me emphasize, to avoid misunderstanding,
that this was neither a 'compiled hypertalk' nor a new
'object-oriented' hypertalk, but simply a way to code on a higher
level than hypertalk in order to make up for its lack of
expressiveness.  It was a cute example of hairy scripting (it has a
smalltalk-like browser to facilitate access to code, too) but was not
an answer to Hypertalk's problems.  I don't have the presenter's name
handy, but you might contact Apple.  They probably won't allow him to
release it, but you might be able to find out something about how he
implemented it.

Doug Felt
Courseware Authoring Tools Project
Sweet Hall 3rd Floor
Stanford University
Stanford, CA 94305
duggie@jessica.stanford.edu