Question regarding scripting support in OO3

[Timothy J. Wood]

On Wednesday, May 5, 2004, at 08:36  PM, Michael Terry wrote:
> 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.

   Actually, I'm seeing no 'ID'-ness in Finders references at all.  If I 
do 'folder of front window' I get back something that is like 'folder 
"name1" of folder "name2" ...' and then if I do:

	set MyFolder to folder of front window
	set name of MyFolder to "x"
	properties of MyFolder

   I get the same busted reference problem that OO2 has with moving 
rows.  Maybe this is what you are saying?

> In OO, I think it should be the same:
>
> make row at row id "whatever" -- insert row at top or bottom of row

   Interesting... I'll log a feature request for this.

> 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.

   I'm certainly not interested in non-robust solutions either :)

   I'm getting more convinced that the whole problem here is that the 
'rows' relationship from row/document (i.e., the flattened list of 
descendants of the object) is editable.  If I make this non-editable 
then you can do 'row id "xxx" of MyDoc' (which implicitly goes through 
the 'rows' property) and then get back an indexed based reference that 
would allow you to use that as a relative location basis ("make row 
after MyRow").

   And, you should still be able to make a persistent reference by 
saying something like 'reference to row id "xxx" of MyDoc'

> Yes, rows should definitely have an 'index' property.

   Bug logged.

> 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.

   That's what I hoped.  It sounds like the index based identifiers, 
removing editing on the flattened 'rows' and the ability to do 
'reference to row id "xxx" of MyDoc' should fit the bill and should be 
robustly implementable.  Let me know if I've misunderstood :)

   Thanks for the feedback!

-tim