Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!bayes
From: bayes@hpfcdc.HP.COM (Scott Bayes)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Wish list (Was Re: What to do about > 32K of data?)
Message-ID: <10520024@hpfcdc.HP.COM>
Date: 3 Apr 89 19:25:06 GMT
References: <7526@phoenix.Princeton.EDU>
Organization: HP Ft. Collins, Co.
Lines: 32

>Records (a la Pascal).  I suppose i could kluge it by assigning globals
>to item numbers and then referring to "item [fieldname] of [recordname]"
>but this gets cumbersome.

This strikes as a case where user-definable objects would be a useful general
tool in which to implement a particular need. We have only 5(?) object classes
now: button field card bkgnd stack. What about some "new" messages:

put "subfield: nameField, dateField" into classInfo
new class record classInfo --defines class "record", described by classInfo
new record myRecord --works like "new button" menu item, etc. creates
		    --new object of class record, named "myrecord"
put "Scott" into subfield "nameField" of record myRecord --"subfield" could be 
						         --optional
--and,
put "on mouseUp" & return & "put empty into subfield" && quote & "nameField" 
& quote && "of me" & return & "end mouseup" into the script of myRecord
--and,
set the icon of myRecord to 1124 --whatever

You'd need an "object tool" with which to manipulate these beauties if you
give them a full iconic/graphic HyperCard type interface, else you could only
manipulate them "scryptically" :-)

I have no full definition for the language in which classInfo might be 
described. The above is just a limited example. Defining subcontainer names
(the "subfield" stuff above) may not be the only thing to be done in a class
definition.

Objects "for the rest of us"??!??!

Scott (not the Scott who posted the included text) Bayes