Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
- Subject: Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
- From: Philip Aker <email@hidden>
- Date: Sat, 20 Dec 2008 06:43:26 -0800
On 2008-12-18, at 00:38:00, Chris Page wrote:
[…]
I do think OSA is a win, in that it gives you a generic way to run
and manipulate scripts that may have completely different syntaxes
and runtimes.
I appreciate that aspect. The design of the handler set as whole has a
huge appeal over here.
Unfortunately, OSA as it exists today is a bit crufty
I agree with the "bit" part. That is to say, it's not too bad
considering that the design has stood the test of time with only
relatively minor modifications being made to accommodate changes in
the OS (FSSpec and Str255 e.g.). But I would like to comment on a
couple of the recent changes because the way I see it, they weren't
thought through completely in terms of a stronger future for OSA.
What I mean is that in order for any facility to be globally viable
these days, it has to be usable on multiple platforms. In order to
regain that ability, OSA should be expressed in terms of something
that can work in that arena. One of the few things that Apple has that
cuts this level is CoreFoundation (which BTW is thought of highly
enough that Google now has a project for it). Therefore I think that a
non-crufty OSA should be expressible in terms of CoreFoundation to
keep its prospects bright in the largest scope possible.
The items I'm thinking about are:
1. OSALoadFile(), OSAStoreFile(), OSALoadExecuteFile(), and
OSADoScriptFile() are wrong. They should be: OSALoadURL(),
OSAStoreURL(), OSALoadExecuteURL(), and OSADoScriptURL().
2. Where the location of a script file can be obtained in one's
handler for OSASetScriptInfo(), the type of object passed should
actually be a CFURLRef instead of an FSRef.
3. While I do appreciate the sheer relief of the new calls
OSACopyDisplayString() and OSACopySourceString(), the use of a
CFAttributedStringRef entails a leap of two levels up to CoreText to
get anything other than than CFAttributedStringCreate(). It seems
unlikely that CoreText will be made multi-platform capable to the
extent that CoreFoundation is so I suggest that the use of an
OSAAttributedStringRef be an alternate. This will be a minimal style
specification easily mapped to native facilities for implementors who
must necessarily integrate with the higher level OS facilities. I
think there would be only kOSATextAttributeFontFamily,
kOSATextAttributeFontSize, kOSATextAttributeBold,
kOSATextAttributeItalic, kOSATextAttributeNormal, and
kOSATextAttributeCFRange keys in an array of dictionaries associated
with the script text.
and harder to add new languages to than it could be.
I don't have much comment in this area except to say that using OSA-
specific Info.plist keys could take over all the stuff that's
currently in a component's resource file.
... how the Apple Event Object Model can subsume huge portions of
XML without working up a sweat ...
You'll have to tell me more about that. I'm not sure what you mean.
I mean that the analogy for an XML element's attributes is expressed
in the Apple Event Object Model as a class's property. But a property
can be complex in AEOM (i.e. the equivalent of an XML element) whereas
it's limited to simpleTypes in XML <http://www.w3.org/TR/xmlschema-2/#rf-defn
>. Furthermore AEOM has more integrity in that queries are formatted
in terms of its own model whereas the analogous facility for XML is in
XPath (which is not a declarative language). The incredibly huge
chagrin for Apple here is that it's failed to realize the superiority
of the design. Because of that, there's now about a zillion developers
working on the many facets of XML to bring it to international
manifestation and dominance and only about 1 working on AEOM.
... the benefits of sdefs towards defining a modern AppleScript
while still retaining huge portions of the original design…
1. Everybody should start using sdefs and stop using aete resources
and .scriptSuites.
Agree. Because a description of the language is now effectively voiced
in XML then it follows that an arbitrary script could be fully and
unambiguously described by the same. Think multi-platform.
2. sdefs combined with Cocoa Scripting are the easiest way to
implement scriptable applications and are miles ahead of
implementing scriptability yourself using the C APIs.
The AppleScript team should be doing a CoreFoundation or CoreServices
implementation for the basic facilities and toll-free bridge to Cocoa
for everything possible. I hope you're the team member who can realize
the gist of the previous paragraphs for global scope. Perhaps your
statement: "manipulate scripts that may have completely different
syntaxes and runtimes" leaves you open to updating OSA in the spirit
I've been trying to communicate.
BTW, I'll be re-iterating a lot of the above in an enhancement request
for OSA.
Philip Aker
echo email@hidden@nl | tr a-z@. p-za-o.@
Democracy: Two wolves and a sheep voting on lunch.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden