Re: a date is not a date? Or: Why I sometimes hate AppleScript...
Re: a date is not a date? Or: Why I sometimes hate AppleScript...
- Subject: Re: a date is not a date? Or: Why I sometimes hate AppleScript...
- From: deivy petrescu <email@hidden>
- Date: Sat, 9 Feb 2008 13:33:04 -0500
On Feb 9, 2008, at 12:49, has wrote:
On 9 Feb 2008, at 16:29, deivy petrescu wrote:
As people have already pointed out, this is a clash in nomenclatures.
iTunes defines year as a property of audio CD playlist.
[...]
As for you hating AS, this is your call, but mostly I feel that
problems arise because of the implementors.
Nope, its AppleScript's fault. Terminology conflicts are an
inevitable consequence of its design, and an object lesson in why
it's a bad idea to combine arbitrarily extensible grammar with dumb
character-based source code.
I completely disagree and agree with you here.
I completely disagree: it is not AppleScript's fault!
I completely agree: "Terminology conflicts are an inevitable
consequence of its [AppleScripts] design".
AppleScript is not Python, Ruby, Perl or whatever, it is AppleScript.
AS is very versatile since it allows other apps to speak its language.
This is not so with the other scripting languages above.
In your example below, you capture a date from AS (sort of) and use it
in Python.
It is not different that what Skeeve proposed as his solution:
tell application "iTunes" to set da to date added of selected track
tell application "System Events" to get year of da
One of my problems with your criticisms of AS is that you look at it
as if it is a scripting language.
It is *more* than that, it is an *inter application scripting* language.
Because of the above it will be always plagued with the terminology
conflict, as you said.
It's neither reasonable nor realistic to expect application
developers to know of, and avoid, every single keyword that might
someday be used by some other osax or AppleScript itself, and
completely unfair to blame them when such conflicts do occur.
I completely agree with you here. Sometimes this conflicts will be
absolutely unavoidable and there is not point in finding a culprit.
However, there are sometimes where those conflicts arise because of
poor implementation of AS on the part of the developer. Still this is
not a major crime. I rather have those conflicts than a *pure*
scripting language.
These problems simply don't exist in languages that have a stable,
unambiguous grammar, e.g. the following works perfectly in Python
with nary a peep about invalid syntax or unknown properties or any
of that other cryptic nonsense that AppleScripters have to put up
with:
Here I completely agree to disagree. I believe that you are comparing
apples and oranges. If one is interested in creating a scripting
language with the power of python (which can be used to write
compilers) with AS's syntax, one should be summarily shot! :)
from appscript import *
tracks = app('iTunes').browser_windows.first.selection()
for track in tracks:
date = track.date_added()
print type(date)
print date.year
The only terminology conflicts for which application developers
might reasonably take some responsibility are those that occur
between keywords in the application's own dictionary - e.g. if a
class and a property both have the same name, - although these sorts
of limited conflicts are still largely Apple's fault for creating
the whole human-readable names versus raw Apple event codes
dichotomy in the first place.
Not really. Sometimes developers use terms which are well known terms
of the Standard Suite for instance. As for your second point, I
believe that choosing the English like, if you will, term makes it
that much easier for the uninitiated to get started.
There are rumors of people who started with AS and now are full
fledged programmers in other languages, believe it or not... :)
has
Deivy
PS. As Michelle puts, I believe that the specific problem that this
thread is about, date in itunes is Apple's fault, but not AS's fault!
_______________________________________________
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