Re: Briskets (perl)
Re: Briskets (perl)
- Subject: Re: Briskets (perl)
- From: email@hidden (Michael Sullivan)
- Date: Wed, 15 May 2002 09:08:49 -0400
- Organization: Society for the Incurably Pompous
Lee Azzarello <email@hidden> writes:
>
On Mon, 13 May 2002, Michael Kelly wrote:
>
> Then again, I've seen some AppleScript that beats that little bit right into
>
> the ground as far as nonunderstandability goes, so I guess the sword cuts
>
> both ways.
>
If I may, I'd like to get a feeling about code literacy and plain english
>
metaphors. I'm just picking up AppleScript and I'm noticing that the
>
"plain english" thing is more deceptive than it seems. Assuming there are
>
many seasoned programmers on this list, I'm curious what people's opionins
>
are of languages that attenpt to use this plain-engligh/natural-language
>
thing when it comes to programming a computer. Is it worth it? Or does it
>
further obfucate code literacy?
I don't know whether it's "worth it" in the sense of what had to be done
to implement the language. But now that we have it, I think it's worth
using.
At first I had a similar frustration, but as I've done more vanilla, raw
applescript programming, I'm finding I rather like the language.
English is definitely a bugaboo. I think many folks problems in this
regard stem from wanting it to accept generic english commands.
Unfortunately, it doesn't. It's still very much a computer language,
and is only "english-like".
Once you get familiar with the dialect involved, though -- it does seem
to read more easily than other languages (when well written and
formatted).
The biggest problem with learning AS, is not AS itself but the
scriptable apps' dictionaries. I banged and banged and hurt my head a
lot before being able to get what the heck is going on in Quark Xpress,
for instance. Even now that I've written a whole pile of Quark scripts,
and am getting really comfortable with applescript, the raw language --
I still get a bad taste in my mouth when I have to write an Xpress
scripts, and sometimes do things like implementing a hash table in raw
applescript as an excuse to procrastinate doing real work...
Raw applescript is now *fun* for me. Scripting Quark is still not fun
-- it's work. Why? Because the dictionary doesn't match what can
actually be done. Things that are really necessary to doing elegant
scripting have bugs that make them very nearly unusable (we had an
example of a whose clause bug in Xpress on the list the other day).
I feel like I could script Xpress for another 2 years and not
familiarize myself with all the quirks involved. Maybe Hans or Shane
has a different opinion since they've been doing it a lot longer, but
I'm tempted to try InDesign and see if it's any better, because I'm so
sick of trying to figure out what the sick bastards at Quark were
thinking.
From what I see on this list, the same thing is true for a lot of other
apps, once you get beyond their own "Bob the folder" stage.
>
Now I'm trying to learn AppleScript and finding that it has some OO stuff
>
going on but it seems to get obfuscated by the plain english thing.
I don't think it's the plain english, but the fact that AS uses
different terminology from every other OO language I've ever seen, and
unlike other languages, the docs don't give good translations.
In AS, a script is an object class definition.
script foo
property bar : {1,2,3}
property baz : "Hello World"
on showDialog()
set aMessage to ""
repeat with i from 1 to some item of bar
set aMessage to aMessage & baz & return
end repeat
display dialog baz
end showDialog
on setMessage(newMessage)
set baz to newMessage
end setMessage
end script
properties within the script are data members, and handlers are methods.
There is no private/public/protected distinction.
If you want multiple instances of an object, you have to wrap it in a
handler that will "run" it and return the resulting object.
on initscriptfoo()
script foo
property bar : ""
on doNothing()
end doNothing
end script
return foo
end initscript
Then in the client script, you can
set firstfoo to initscriptfoo()
set secondfoo to initscriptfoo()
And you have two separate instances of the same object class.
Note that all script files have an implicit script/end script wrapper,
so they can be accessed by filename and treated as script objects.
So 'load script [alias|file] pathstring' does essentially the same thing
as my "initscriptfoo()" handler for any AS compiled script or applet.
Any code in a script object that is not wrapped in a handler is
implicitly wrapped in an on run() handler with no arguments. So it will
run when you "run script" This means that every script has a "run"
method, though any script with no code outside other handlers will do
nothing when you access it.
Anyway, that's my short "What you need to know about applescript OO
terminology, before you try to make sense of the language guide" speech.
And I sympathize, because I had no clue what was going on in the ASLG's
section about this stuff, until I'd seen enough questions, answers and
code examples on this list to figure out (or have someone make explicit)
those terminology translations. Suddenly, all was light.
Michael
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.