• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
      • From: Philip Aker <email@hidden>
References: 
 >Re: Tell Blocks Considered Harmful (was Re: open for access) (From: has <email@hidden>)
 >Re: Tell Blocks Considered Harmful (was Re: open for access) (From: Chris Page <email@hidden>)
 >Re: Tell Blocks Considered Harmful (was Re: open for access) (From: Philip Aker <email@hidden>)
 >What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…) (From: Chris Page <email@hidden>)
 >Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…) (From: Philip Aker <email@hidden>)
 >Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…) (From: Chris Page <email@hidden>)
 >Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…) (From: Philip Aker <email@hidden>)
 >Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…) (From: Chris Page <email@hidden>)

  • Prev by Date: Re: Application Script Menus
  • Next by Date: Re: libraries vs copy/paste
  • Previous by thread: Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
  • Next by thread: Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
  • Index(es):
    • Date
    • Thread