Re. third-party dependencies [was Re: Stock Quotes using AppleScript]
Re. third-party dependencies [was Re: Stock Quotes using AppleScript]
- Subject: Re. third-party dependencies [was Re: Stock Quotes using AppleScript]
- From: has <email@hidden>
- Date: Sat, 14 Mar 2009 20:56:08 +0000
Shane Stanley wrote:
To split hairs even further, Smile is not available on *any*
Macs by default. Not that there's anything wrong with that.
Although it could be argued that there *is* something wrong with the
fact
that several of the functions Satimage.osax provides aren't
available via
AppleScript in a default install. Wanting to sort a list or change
the case
of some text, for example -- they're not exactly obscure requirements.
Absolutely. This is the biggest single reason I moved to Python
+appscript for 99% of my application scripting work. The only times I
write AppleScript code now are when I need a quick one-or-two-line
script to send some commands to an application (e.g. open a remote
session in ARD), which is slightly quicker to type in AS, or need
attachability features (e.g. Mail rules) which only AS fully supports.
For anything else, Python's built-in features and standard libraries
blow away AppleScript's - e.g. changing case and sorting items are
built directly into Python's string and list objects.
And I'm not sure that the idea of having third-party additions
installed by
default, even if in a place where they're not activated by default,
is so
outrageous in a system where there are several gigabytes of print
drivers of
sometimes dubious quality installed on behalf of third parties.
I think it's more a logistical concern. Any time Apple includes third-
party executable code on their system, they're taking responsibility
should something go wrong. Even the other bundled scripting languages
only include a bare minimum of extras: e.g. PerlObjC and Mac::Glue in
the standard Perl install, PyObjC for Python and RubyCocoa for Ruby.
And that's only so Apple can tout their own Cocoa libraries to Perl,
Python and Ruby developers; if they want anything else, they need to
install it themselves.
Oh, and the hassles cut both ways. Once a third-party add-on is
bundled in the system, those third-party developers are basically
stuffed if they want to make any non-security updates to it outside of
OS X's major revision cycle. This is why a lot of Python, Ruby, Perl,
etc. users end up installing their own copies of those languages
anyway: when a new OS X release ships, its own copies of Perl, Python
and Ruby are often at least a minor revision behind, and by the time
the next OS X release comes around they're usually trailing by a major
revision or more.
One suggestion I would make is that AppleScript allow developers to
include osaxen inside of script bundles (.scptd files). Bundle-based
applets can already include required osaxen in Contents/Resources/
ScriptingAdditions, but that's no good if you're distributing scripts
for use in, say, Script menus or Mail's rules, which require a
compiled script file, not an applet. If someone wants to file feature
requests on this, please be my guest.
Regards,
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
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