rene@ascom.uucp (Rene Bach) (01/16/90)
I feel HC is not text based. I would expect a hypertext based system to allow easy cross referencing of FREE text. This issue doesn't appear to bother people. However I find it the best programming interface available to program the Mac. I am surprised nobody (else I have missed it, in this case please ignore) has mentioned that send doesn't work with arguments (parameters) (hypercard 1.2.2 and below). Am I correct or am I missing something ? I have tried: send message_name arg1,arg2 to card card_name and the message doesn't get sent ??? send message_name to card works. Since the basic message passing routine fails, HC can't be a OOP language. The other issue is that things get really slow on a Mac + (my scripts' listing is about 5 printed pages, all stored in 2 backgrounds and the stack). Is anyone working on a script compiler ? Selecting the drawing tool, then drag the pointer and change the tools selection doesn't seem to be a speedy interface (it looks like I can draw faster). I am implementing a sailing simulator and drawing boat courses and moving boat icons around. The speed issue makes me wonder whether I want to continue and simulate more than ONE boat. Thanks for any feedback Rene Switzerland
jdevoto@Apple.COM (Jeanne A. E. DeVoto) (01/17/90)
In article <614@ascom.UUCP> rene@ascom.UUCP (Rene Bach) writes: >I feel HC is not text based. I would expect a hypertext based system to allow >easy cross referencing of FREE text. This issue doesn't appear to bother >people. You are correct: HyperCard is not a text-based hypertext platform, nor was it intended to be (although you can develop a hypertext application as a stack). >I am surprised nobody (else I have missed it, in this case please ignore) >has mentioned that send doesn't work with arguments (parameters) >(hypercard 1.2.2 and below). Am I correct or am I missing something ? >I have tried: > send message_name arg1,arg2 to card card_name and the message > doesn't get sent ??? > send message_name to card works. What you're missing is that the argument to "send" must be a string (or an expression that evaluates to a string). In other words, the syntax of the send keyword looks like send <message> to <object> The easiest way to make a multi-word expression into a string is to enclose it in double quotes. >Since the basic message passing routine fails, HC can't be a OOP language. Uh, yeah. >Selecting the drawing tool, then drag >the pointer and change the tools selection doesn't seem to be a speedy >interface (it looks like I can draw faster). I am implementing a sailing >simulator and drawing boat courses and moving boat icons around. The speed >issue makes me wonder whether I want to continue and simulate more than >ONE boat. Changing between tools is pretty slow, although it is considerably faster in 1.2x than in previous versions. You may want to consider using card- flipping techniques in addition to (or instead of) drawing on the screen; if the animation you need to do is simple enough, flipping from card to card is quite a bit faster than drawing. -- ====== jeanne a. e. devoto ======================================== jdevoto@apple.com | You may not distribute this article under a jdevoto@well.UUCP | compilation copyright without my permission. ___________________________________________________________________ Apple Computer and I are not authorized | CI$: 72411,165 to speak for each other. | AppleLink: SQA.TEST
ba0k+@andrew.cmu.edu (Brian Patrick Arnold) (01/17/90)
Also, If, for example, you want to redirect a message to another object, thus sort-of-implementing class-based message-passing, you can do the following: ON Yowza Foo "Whoagolly, gee", whiz END Yowza ON Foo bar,cat,dog SEND "Foo bar,cat,dog" to button "Ziggy" END Foo This will preserve the (non-)existence of parameters, e.g., if the caller passed nothing, nothing continues to be passed, and individual parameters like "Whoagolly, gee" aren't evaluated until button "Ziggy" actually gets them. E.g., this example would pass "Whoagolly, gee" as the first parameter, bar, and "whiz" as the second parameter, cat. Wunderkind keyword empty is passed as dog. To do OOP-like programming, you'd have to come up with a way of having an object "know" its class and redirect messages to scripts set up as individual classes. You could also implement inheritance in this way, having the "class" object "know" its parent class. It would be a bit of work with lots of caveats and wouldn't exactly be blazing. I wish to God HyperCard supported classes and inheritance in a more OOP style. Rhetorical Complaint #336237: could somebody show me how to "send" a function call and get its result? - Brian
jk3t+@andrew.cmu.edu (Jonathan King) (01/17/90)
send mouseuUp to button "pushMe" [Hypertalk Script Language Guide p. 74] where mouseUp is certainly *not* a string. This works because "quotation marks around the message are not required if the message is a single word." [HSLG p. 74] I assume that this "feature" was designed to help out novice programmers write simple scripts, but the only thing I have seen it do is frustrate the hell out people before they finally figure out what is going on. And now, if you fixed the "feature", everybody's scripts would break in weird places. This problem with strings/quotation is not limited to the "send" keyword by any means; it screws up object naming, too. Thus while you would expect enclosing an expression in quotes would force hypercard to consider the expression a string, this won't always happen. Thus HSLG p. 35 notes that card "1812" doesn't refer to the card whose *name* is "1812" but to the card whose *number* is 1812 in that stack. Or is that the id number...hmm, better look that up again, I guess. Admittedly, this doesn't get you into trouble as often, but I still don't think it's very consistent. Another senseless "gotcha" is the fact that Hypercard silently assumes that when you write 'field "foo"' that you mean 'background field "foo"'. I suppose this "feature" saves a couple of key strokes now and then, but I know that it can cause very subtle bugs. [And let's not forget the 'card field id 7' problem mentioned on p. 36 of the HSLG.] > >Since the basic message passing routine fails, HC can't be a OOP language. > > Uh, yeah. It is true that message passing works, but HC certainly lacks many desireable features that an object-oriented programming language could have. Like, say, user-definable objects with local instance variables. I'm sure I'm not the only person who dislikes having to kludge objects together with hidden card fields, or unencapsulated global variables, or other weird tricks. I'm not saying that Hypercard has to be Smalltalk or CLOS, but let's get beyond the real weirdness. I also get depressed when I know *exactly* what the new button should look like, and where it should be, but I still have to 'domenu "New Button" etc.' This is really bad when a user is waiting. [NB--I have been using icon buttons that the user can move around as chess pieces in one program, and as animated objects that a user can create at will in another--when do we get sicn buttons? This, too, is slightly kludgey, but I don't mind yet because it's pretty neat :-).] > >Selecting the drawing tool, then drag > >the pointer and change the tools selection doesn't seem to be a speedy > >interface (it looks like I can draw faster). I am implementing a sailing > >simulator and drawing boat courses and moving boat icons around. The speed > >issue makes me wonder whether I want to continue and simulate more than > >ONE boat. > > Changing between tools is pretty slow, although it is considerably faster > in 1.2x than in previous versions. You may want to consider using card- > flipping techniques in addition to (or instead of) drawing on the screen; > if the animation you need to do is simple enough, flipping from card to > card is quite a bit faster than drawing. This is also true, but you have to draw those pictures sometime, and unless you have an application where you know *exactly* what you need to show beforehand, card-flipping can't hide the time you need to draw things on a card (not on the screeen, right?) And card-flipping itself isn't always as speedy as you would like (although it usually does the job). Quickdraw is really quick, and PICTs can be replayed... but you can't show a pict without writing an XCMD, and I feel squeamish about doing that since HC should (in my opinion) control this sort of thing itself. MACL does a great job with this kind of thing, and Apple liked THAT product so much that it bought the company. > -- > ====== jeanne a. e. devoto ======================================== > jdevoto@apple.com | You may not distribute this article under a > jdevoto@well.UUCP | compilation copyright without my permission. > ___________________________________________________________________ > Apple Computer and I are not authorized | CI$: 72411,165 > to speak for each other. | AppleLink: SQA.TEST I really do like Hypercard, but I would just love to see Hypertalk mature into something that's really powerful and really elegant; a language that other programmers would envy. Give us the tools and we can build incredible things. jking (jk3t+@andrew.cmu.edu)
dce@smsc.sony.com (David Elliott) (01/18/90)
In article <YZgxUf_00WB585dlsh@andrew.cmu.edu> jk3t+@andrew.cmu.edu (Jonathan King) writes: >send mouseuUp to button "pushMe" [Hypertalk Script Language Guide p. 74] > >where mouseUp is certainly *not* a string. This works because >"quotation marks around the message are not required if the message >is a single word." [HSLG p. 74] I assume that this "feature" was >designed to help out novice programmers write simple scripts, but the >only thing I have seen it do is frustrate the hell out people before >they finally figure out what is going on. And now, if you fixed the >"feature", everybody's scripts would break in weird places. I got caught by this one recently. I had a button named "Volume" and a global named "volume". I decided to change my ways and start all globals with upper-case letters (like I do in Unix programs). The next thing I knew, I was getting errors for statements like send "mouseUp" to button Volume Maybe there could be a "developer's mode" where syntax would be more strictly checked. That is, any time a parameter is a string, it must be quoted. This would be off by default, but could be turned on for a given stack by the developer. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "Baziotes! Baziotes! Getcha red hot Baziotes here!"