Re: robust handling of return values
Re: robust handling of return values
- Subject: Re: robust handling of return values
- From: has <email@hidden>
- Date: Fri, 11 Nov 2005 17:00:10 +0000
patrick machielse wrote:
>I've noticed that some AppleScript commands don't return values of 1 predefined type, but can return an 'array' of different things. [...]
>Now on to my question: how do I robustly check the result value of the 'add' command?
Awkwardly. Performing a coercion on the command's immediate result seems to work (touch-wood):
tell application "iTunes" to set L to (add {}) as list
L --> {}
The same trick works for apps like Address Book that return no value when a property is empty:
tell application "Address Book" to set s to last name of person "Dave" as Unicode text
s --> ""
>A related question: why wouldn't the 'add' command just return an empty list if no tracks were added? Why make it difficult?
Partly because application developers sometimes make mistakes, but mostly because this part of AppleScript was badly designed in the first place.
The smart thing would've been for AppleScript commands to _always_ return a result (i.e. make them expressions). Instead, it's a bit like BASIC: you've got commands which return a result (analogous to BASIC functions) and commands which don't (analogous to BASIC procedures). This reflects the nature of Apple events, where return values are not compulsory, but there's no reason AppleScript couldn't have been smart enough to return a 'none' object when the application itself returns no value. (This is what Python's appscript bridge does, for example.)
Instead, the onus is on the application developer to ensure that commands that are expected to provide a result always supply an explicit 'missing value' object when they've no specific value to return. Having two different ways to essentially say 'no value' is a dumb set-up, and sometimes developers use the wrong one, either because they made an error or because they're not aware that the issue exists.
There's not much that can be done to address the none-vs-missing-value dichotomy at source now, as to change it now would raise backwards-compatibility issues, but users can help rectify problems on the application side by filing bug reports with the relevant developers.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden