Mac::Glue Thoughts

I am kinda thinking aloud about some things ... feel free to toss in your two cents.

$ osascript -e 'tell app "Finder" to get name of startup disk'
Sweeney

startup disk is what AppleScript calls a property. Each class can have properties, some of which are read-only, some of which are read-write. If you open the Finder's dictionary in Script Editor, under the application class you will see numerous properties, one of which is startup disk. Classes can also have elements, which are essentially other classes which can be referenced by some identifier (name, index, ID).

get startup disk -- <i>startup disk</i> is property of Finder
get name of startup disk -- <i>name</i> is property of <i>startup disk</i>
get disk 3 -- 3 is the numeric index of the wanted element <i>disk</i>
get disk "Sweeney" -- "Sweeney" is the name of the wanted element <i>disk</i>

Each element is an object of a specific class. Each property also is of a specific class type, and inherits from that class type. So startup disk is an object of class disk. If you select the disk class in the dictionary, you see what elements and properties it can have, and what else it inherits from (in this case, the container class). If you look at the container class you can see it inherits from item, which describes the name property. So we can get the name of startup disk because it isa container isan item which has a name.

I needed to figure out how all these things worked together for Mac::Glue to work, since I am essentially rewriting AppleScript in Perl syntax. One of the downsides is that in order to take full advantage of Mac::Glue, you need to understand a lot of this stuff, too, at least somewhat. So in Mac::Glue, the above would be:

$finder->get( $finder->prop('startup disk') );

Tell the Finder to get the property startup disk. Simple, right? The get method and startup disk property both belong to the Finder's dictionary, and since Perl doesn't really keep context for OOP, we need to remind it what object we are working with. But with tchrist's help, I do have code that will allow me to do:

for ($finder) {
    $disk = get(prop('startup disk'));
}

It imports AUTOLOAD into the current namespace, and then that AUTOLOAD calls the unknown methods on $_ (which for() set for us). Freaky. But I digress.

The other lines would look like this:

$finder->get( $finder->prop(name => of => 'startup disk') );

I am thinking of ways to make the syntactic sugar of unnecessary, but it is difficult, because with properties and elements are basically the same thing; prop('foo') is just a synonym for obj(property => 'foo'), it is the name of the element property.

$finder->get($finder->obj(
    property => 'name',
    property => 'startup disk'
));

That makes even less sense. But if we had simply name => 'startup disk'", then it would try to get the element name whose identifier is "startup disk". I'd need to know that name is intended to be a property, not an element (I can't look at "startup disk" for the answer, because I could be asking for something actually named "startup disk" instead of the property). Witness the other two:

$finder->get( $finder->obj(disk => 3) );
$finder->get( $finder->obj(disk => "Sweeney") );

And it still makes perfect sense when extended:

# tell app "Finder" to get name of item 12 of disk "Sweeney"
$finder->get(
    $finder->prop(name => item => 12, disk => "Sweeney")
);

Right now, it is essentially figured out by counting: if there is an odd element in the list, it is a property. This works fine except for when you are getting a property of a property. Is it possible to do it this way, to figure out that name is a property? I believe that properties and elements cannot share the same name, so that I can do this. Do I want to even try to do it, will it make it more or less confusing?

Now Playing: Forever Friends - Jon Gibson (Forever Friends)