Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Proposed redesign of AppleScript's filesystem-related classes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Proposed redesign of AppleScript's filesystem-related classes



Hi all,

In connection with another project, I am currently trying to write up a novice-friendly explanation of the degenerate mess that is AppleScript's filesystem-related classes. Not surprisingly, the subject matter is causing some considerable frustration, so in-between all the cussing I've spent a couple hours writing up a first-draft proposal for straightening out the existing shambles. Before firing it over the Radar event horizon, I thought I would post it here for other folks to review and perhaps assemble some popular support behind it, so please let me know what you think.

Cheers,

has

-------------------------------------------------------------
Proposed redesign of AppleScript's filesystem-related classes


0. The goal is to replace the current chaos of AppleScript's filesystem-related classes and pseudo-classes (alias, POSIX file, file, «class furl») with a single robust, coherent API while preserving backwards compatibility with older scripts and existing applications.




1. There should be two official AppleScript-defined classes: 'alias' (for identifying existing filesystem objects) and 'file' (for identifying arbitrary filesystem locations).

1a. 'POSIX file'/'«class furl»' should still be supported, but deprecated in favour of the new 'file' class.




2. Both alias and file objects may be created using literal specifiers, e.g.:

	alias "Macintosh HD:Users:jsmith:"
	--> alias "Macintosh HD:Users:jsmith:"

	file "Macintosh HD:Users:jsmith:"
	--> file "Macintosh HD:Users:jsmith:"


2a. POSIX file specifiers should still be supported for backwards compatibility, but should be deprecated in favour of file specifiers. POSIX file specifiers should return objects of class 'file':

	POSIX file "/Users/jsmith/"
	--> file "/Users/jsmith/"

	class of POSIX file "/Users/jsmith/"
	--> file




3. Both alias and file objects should provide 'class' properties that return 'alias' and 'file' respectively:

	class of alias "Macintosh HD:Users:jsmith:"
	--> alias

	class of file "Macintosh HD:Users:jsmith:"
	--> file


3a. For backwards compatibility with existing scripts, the following comparisons should all return true:

	file = POSIX file

	file = «class furl»

	«class furl» = POSIX file

(This is analogous to the following 10.6 comparisons: text = string, string = Unicode text, Unicode text = text; all of which return true.)




4. To support both HFS and POSIX paths and provide backwards compatibility with existing scripts, alias and file specifiers should support both by-name and by-id reference forms.


4a. The by-name form should be used to create alias and file objects from HFS path strings:

	alias "Macintosh HD:Users:jsmith:"


4b. The by-id form should be used to create the same objects from POSIX path strings:

	alias id "/Users/jsmith/"




5. To make API symmetrical, both alias and file objects should provide an 'id' property that returns a POSIX path string:

	alias "Macintosh HD:Users:jsmith:"
	--> "/Users/jsmith/"

	alias id "/Users/jsmith/"
	--> "/Users/jsmith/"


5a. Alias and file objects should also support a 'POSIX path' property for backwards compatibility, but this should be deprecated in favour of the 'id' property.




6. Both alias and file objects should support coercions to and from text, using HFS path strings in all cases:

	"Macintosh HD:Users:jsmith:" as alias
	--> alias "Macintosh HD:Users:jsmith:"

	alias "Macintosh HD:Users:jsmith:" as text
	--> "Macintosh HD:Users:jsmith:"

	alias id "/Users/jsmith/" as text
	--> "Macintosh HD:Users:jsmith:"


6a. Coercions between alias and file objects should also be supported.


6b. Coercing POSIX path strings, alias and file objects to 'POSIX file' should be supported for backwards compatibility, but this should be deprecated in favour of coercing to 'file'. In all cases, the result should be an object of class 'file'.




7. When AppleScript packs/unpacks an Apple event:

- an alias object should pack as an AEDesc of typeAlias

- an file object should pack as an AEDesc of typeFileURL

- an AEDesc of typeAlias should unpack as an alias object

- an AEDesc of typeFileURL should unpack as a file object




8. Because AppleScript evaluates specifier literals differently depending on whether they are inside or outside a 'tell application' block, and because alias and file specifiers have special meaning to AppleScript but may also have special meaning to some scriptable applications, some additional rules will be required to disambiguate these situations.


8a. When evaluated outside of any 'tell application' blocks, AppleScript will attempt to resolve the specifier itself. In this case, the following rules should be used:

- an alias specifier literal should return an AppleScript object of class 'alias'

- a file specifier literal should return an AppleScript object of class 'file'




8b. Evaluating alias and file specifier literals that appear inside 'tell application' blocks requires more complex rules.

8b1. When evaluating a specifier literal within a 'tell application' block, if the specifier is not written as an 'a reference to' operator's operand, a tell block's target or application command parameter, then the normal AppleScript behaviour is to send it to the target application in a 'get' event (a.k.a. 'implicit get'). However, as alias/file specifier literals are special cases in that they are also recognized by AppleScript, they require special handling:

- if the application's dictionary defines an 'alias'/'file' class, then the normal implicit get approach should be used

- if not, an alias/file specifier should return an AppleScript object of class 'alias'/'file'

This should ensure that an application is only asked to resolve an 'alias'/'file' specifier if there is a high degree of confidence that the application will know how to do so. e.g. Finder, System Events both define a 'file' class and know how to interpret file specifiers. (Note: if an application defines an 'alias'/'file' class and doesn't know how to interpret an alias/file specifier, then that should be regarded as a design defect in the application.)

At the same time, it will prevent a file/alias specifier that should be sent to the application to resolve from being converted by AS instead. e.g. A file specifier within a 'tell application "Finder/System Events"' block should be sent to the application as an AEDesc of typeObjectSpecifier.

8b2. In addition, where the specifier literal does appear as an 'a reference to' operator's operand, a tell block's target or application command parameter, it will be packed into outgoing events as an AEDesc of typeObjectSpecifier whose desired class is typeAlias/typeURL and whose container is null. Since most applications will require an AEDesc of typeAlias/typeFileURL/typeFSRef/typeFSS, provide system-level coercion handlers for coercing the former typeObjectSpecifier AEDescs to typeAlias/typeFileURL/typeFSRef/typeFSS.


8c. Note that other specifier literals that are recognized by AppleScript - e.g. string id {…}, date "…" - would benefit from following the same rules.


8d. The following test cases should all work as described:

-- AS creates an alias object
set f to alias "Macintosh HD:Users:jsmith:ReadMe.txt"
tell application "TextEdit"
	-- AS packs alias object into 'open' event as typeAlias
	open f
end tell

tell application "TextEdit"
	-- AS creates an alias object (since TextEdit's dictionary doesn't define an 'alias' class)
	set f to alias "Macintosh HD:Users:jsmith:ReadMe.txt"
	-- AS packs alias object into 'open' event as an AEDesc of typeAlias
	open f
end tell

tell application "TextEdit"
	-- AS packs an AEDesc of typeObjectSpecifier (desired type='alis') into 'open' event;
	-- application asks AEM to coerce AEDesc from typeObjectSpecifier to typeAlias
	open alias "Macintosh HD:Users:jsmith:ReadMe.txt"
end tell


-- AS creates a file object
set f to file "Macintosh HD:Users:jsmith:ReadMe.txt"
tell application "Finder"
	-- AS packs alias object into an 'open' event as an AEDesc of typeFileURL
	open f
end tell

tell application "Finder"
	-- AS packs an AEDesc of typeObjectSpecifier (desired type='file') into implicit 'get' event;
	-- application returns new object specifier
	set f to file "Macintosh HD:Users:jsmith:ReadMe.txt"
	-- AS packs new object specifier into 'open' event
	open f
end tell

tell application "Finder"
	-- AS packs an AEDesc of typeObjectSpecifier (desired type='file') into 'open' event
	open file "Macintosh HD:Users:jsmith:ReadMe.txt"
end tell

tell application "Finder"
	-- AS packs an AEDesc of typeObjectSpecifier (desired type='file') into 'open' event
	open file "ReadMe.txt" of home
end tell




9. Examples of converting between HFS/POSIX paths and alias/file objects:


set x to alias "Macintosh HD:Users:jsmith:"
--> alias "Macintosh HD:Users:jsmith:"

x as text
--> "Macintosh HD:Users:jsmith:"

id of x
--> "/Users/jsmith/"


set x to alias id "/Users/jsmith/"
--> alias id "/Users/jsmith/"

id of x
--> "/Users/jsmith/"

x as text
--> "Macintosh HD:Users:jsmith:"

"Macintosh HD:Users:jsmith:" as alias
--> alias "Macintosh HD:Users:jsmith:"


set y to file "Macintosh HD:Users:jsmith:"
--> file "Macintosh HD:Users:jsmith:"

y as text
--> "Macintosh HD:Users:jsmith:"

id of y
--> "/Users/jsmith/"


set y to file id "/Users/jsmith/"
--> file id "/Users/jsmith/"

id of y
--> "/Users/jsmith/"

y as text
--> "Macintosh HD:Users:jsmith:"

"Macintosh HD:Users:jsmith:" as file
--> file "Macintosh HD:Users:jsmith:"




--
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-implementors mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.