Question regarding scripting support in OO3

[Michael Terry]

On May 5, 2004, at 1:51 PM, Timothy J. Wood wrote:

> 4) Keep returning index based references but allow you explicitly make 
> a reference to a row by identifier.  This would also be easy, but it 
> loses some of the benefit of having unique identifiers since the 
> following would fail:

This is how I actually expected it to work. I know the canonical object 
specifier is usually supposed to be the least fragile, but the above is 
the way Finder handles it, so it may be most intuitive to frequent AS 
users. In Finder's case, there aren't IDs per se, but the alias type 
functions as an ID.

Of course, OO also has ordered elements in its containers, but that's 
no big deal. Here's how Finder makes a new folder using a unique ID for 
the location:

make folder at folder (choose folder) -- where 'choose folder' returns 
an alias (unique ID)

In OO, I think it should be the same:

make row at row id "whatever" -- insert row at top or bottom of row

Now, what if the order of items in a Finder folder could be user 
specified? A call might look like this:

make folder at after folder 3 of myFolder

But, of course, you could have specified 'file 3' as an alias, too. And 
what would you expect to happen, as a user?

make folder at after (choose folder)

You'd expect it to make a folder in the chosen folder's container after 
the chosen folder, I think. Really, nothing else makes sense. You 
wouldn't expect it to put a folder in the chosen folder, and you 
wouldn't expect it to make a folder at the first available location in 
root. Semantically, this is exactly what an AppleScripter would expect, 
to place the new object after the relative object within the immediate 
container (i.e., parent row).

Which, I suppose, ends up arguing that using IDs as the canonical 
reference form would be best, in my opinion. But you say that that 
would require a little bit of hackery, and that worries me--I'm afraid 
that might make whatever you do more bug-prone. It doesn't bother me 
abstractly, though, because although the AS framework is flexible and 
great, there's no way it could anticipate and elegantly provide for 
every application's model.

If it were much easier and more reliable, I suppose you could require 
insertion locations to be specified by index within the container, like 
the example above with folder 3, and still have the canonical object 
specifiers used IDs. It's not uncommon for location specifiers to be 
different from regular object specifiers. This would be a more 
AppleScripty way to do it than to only be able to specify the location 
by a property record. Actually, though, both should work, which brings 
up another point.

Yes, rows should definitely have an 'index' property. Technote 2106 
talks about this. Where it makes sense and is useful, objects should 
return their indices within their containers. Changing the index should 
move the row to the new position in its container (document or row). 
Note that the 'window' class has an 'index' property, although I 
believe it currently is broken--I remember having to resort to GUI 
scripting to reorder windows.

>
> 	set MyRow to first child of MyParent
> 	move MyRow to after SomeOtherRow
> 	set topic of MyRow to "foo"  -- same old index-base reference breakage
>
>   and you'd need to do something like:
>
> 	set MyID to id of first child of MyParent
> 	move first child of MyParent to after SomeOtherRow
> 	set topic of row id MyID of MyDoc to "foo"
>
>   This would be annoying since you'd have to potentially keep around 
> two references to an object; one based off position and one based off 
> id.
>

I'm lobbying for all IDs all the time, but this isn't a bad second 
choice. A lot of scripts are totally OK without IDs. I know your 
example was just off the cuff, but note that the topic could easily 
have been changed before the move. The point being that in a lot of 
common scripts, IDs aren't necessary. It's just that where they are 
necessary, they're absolutely critical, so in those cases, a little 
extra effort is nothing to lose sleep over. As an example, folks write 
lots of Finder scripts without referring to files as aliases, and even 
when they do, it's most often that they're just more convenient than 
writing long hierarchical containment references. The greatest share of 
advantage to IDs will be just in having them available when we have to 
have them.


Mike