At 2:12 AM +0200 on 5/28/99, M. Uli Kusterer wrote:
>> Or consider this line: "New Archive Pathname archName" Who the @#@*&*!
>> taught you to capitalize? Those Of Us Who Write Proper English Don't
>> Capitalize Like This.
>
>Anthony,
>
> my bet is that the author of the AppleScript dictionary of your
>application (StuffIt?) capitalized the tokens this way.
No doubt. But since AppleScript is not case-sensitive, it should fix this itself.
Of course, you can guess what I think about the patchwork of commands; languages are
supposed to extendable, not mutable.
>
>> And God forbid I try and recapitalize a variable. It changes it back!
>> Who the f**k gave you the duty to undo my fixes to my own code?!?!!!
>
> That's the trouble with code that is saved in tokenized form and then
>re-generated based on dictionary names and tokens. Horrible but
>memory-efficient.
True. But that's why you update your token table on each compile.
But if you look at some of that disassembled OpenTalk, it's worse. I pitty the person
who winds up getting to write the debugger (Ouch. It's probably me)
>
>>I feel much better now.
>
> You can't imagine how glad we all are. Honestly, I have never enjoyed
>writing AppleScripts. When one works, I'm happy and I enjoy that everything
>works, but the worst case I had was when I had a number (from a date) and
>wanted to have a leading zero in it. No problem with HyperTalk's put before
>and length statements, but strangely enough, AS wouldn't recognize the
>month numbers and day numbers as constants. I had to write 9 "if"
>statements to ask for every single one of them ARRRGH!
I hate it's types too. Not even C++ is so strict about demanding "proper" types and
then hiding them from you. "as text" and "as string" and the like are nice but then
there are the (as far as I can tell) AppleScript bugs which will get you.
I thinbk I've got to find the AppleScript bug address. I'll report everything that
ever irks me as a bug -- after all, it's APPLEscript so it certainly should be
user-friendly.
And its dialogs are even worse:
"Can't convert �class TEXTdcba� to �class TEXTdcbz�"
or
"Application Stuffit Lite� can't understand the
[10 lines of nonsence] message. Sei ein Wurm!
Sei gl�cklich! Ein Wurm haben kein AppleScript."
(OK, I added the worm stuff... Uli, how bad did
I screw that up? And which gender is a worm
these days?)
>
>>Yep. Recently, it's been happening in Linux-World.
>
> True, but they'll still have a long way to go until they have caught up
>with the MacOS. But the way Apple are doing at the moment, I hope they'll
>be here fast.
Hmmm... hate the new QT as much as I do? Just dump in the old MoviePlayer. And, btw,
LinuxPPC is _FAST_.
>
>>Hmmm... definitely something that should be addressed in the interpreter.
>
> I don't think we should have "include". We should stay with "insert
>script". It's much better structured and uses HyperCard's message-passing
>hierarchy.
And using HC's hierarchy is a Good Thing? Ak! Makes it hard to compile scripts...
>Scott Raney and I have discussed include several times, but
>besides being unable to come up with a comprehensible name ("include"
>really says nothing, does it?),
I don't see why not. It's an imperitive... It tells the compiler: "Include whatever
[into my source]"
>it'd be an implementation nightmare.
#include is fine; it's preprocessed. I'd just read the file before passing the script
to the frontend. Call that layer the preprocessor.
>And
>people will have problems understanding it.
How about "using script file <file>". No, never mind. That sounds like it establishes
that there is a point at which you un-use it.
Another thing, though. With the HT compiler, one could make semi-protected libraries
for distribution.
