Re: why is applescript so slow???
Re: why is applescript so slow???
- Subject: Re: why is applescript so slow???
- From: Christopher Nebel <email@hidden>
- Date: Thu, 2 Dec 2004 09:46:10 -0800
On Dec 1, 2004, at 5:14 PM, Chris Page wrote:
On Dec 1, 2004, at 15:24, Christopher Nebel wrote:
[An excellent discussion of efficient script writing--thanks, Chris.]
get every person of group gName
repeat with i in the result
delete i
end
... (You ought to be able to say "delete every person of group
gName", and you can, but it only removes them from the group and
doesn't delete them. It's a bug.)
I'm a little unclear on how "delete" should work when items can be
elements of more than one other item.
If I say "delete person 1" I would expect the item to be deleted, but
if I say "delete person 1 of group foo" I'm not sure whether I expect
it to be deleted or merely removed from the group.
Do you think applications should support, say, "remove" to remove
items from groups without deleting them, and that "delete" should
always delete an item no matter how it is referenced?
Yes. To quote TN2106:
Many-to-one and many-to-many relationships
In most applications, all object relationships are one-to-one or
one-to-many, the result being that all objects are contained by
exactly one other object. Some applications, however, have
many-to-one or many-to-many relationships, so a single object may
appear in several different containers. iPhoto behaves like this: a
photo object may be in any number of albums. There is nothing wrong
with this model, but it does require certain adjustments.
First, you must support the commands add and remove. These commands are
designed to only manipulate containment, as opposed to creating and
destroying objects like make and delete do. The distinction is
important because make and delete do not have the proper meanings for
some tasks. Say you want to add an existing photo to an album in
iPhoto. make is not really appropriate, since you’re not making
anything. Similarly, say you want to remove a photo from an album.
delete is ambiguous: will it merely remove the photo from that album,
or will it delete the photo entirely? You could resolve the problem
without different commands by introducing a photo reference object,
except that there is no such thing in the user model, and would
therefore violate the stay on-task guideline.
Second, is it possible for your objects (call them photos, to continue
the iPhoto analogy) to not belong to any specific container (album)?
For example, in iPhoto, a photo may not be in any album. If this is the
case, then you will need to designate a single master container that
holds all the photos; they may be added to and removed from albums from
there. (iPhoto uses application for this.) If not, then you do not need
a master container, but removing a photo from its last album must
delete it.
delete
delete specifier
Removes the specified objects from any containers they may be in and
destroys them. delete should always delete the object, no questions
asked. If you want to have a trash of some sort (such as the Finder
does), define a trash object and let users move objects to it.
Depending on the application model, deleting an object may cause its
container to be deleted as well �C it may not be possible for a
container to have no elements.
remove
remove specifier [from specifier]
Removes the specified objects from their container. If the from
parameter is omitted, it is inferred from the direct parameter if
possible. (For example, in remove first photo of album 1, the from
parameter is understood to be album 1. However, in remove photo id 437,
it is impossible to tell, and the application should return an error.)
Do not support this command if your application has only one-to-one
and one-to-many relationships. remove may or may not delete the
object, depending on the application model; see Many-to-many
relationships for details. Depending on the application model, removing
an object may cause its container to be deleted �C it may not be
possible for a container to have no elements.
Also see the section on many-to-many relationships. I should probably
be more explicit about the relationship between "remove" and
"delete"...
--Chris Nebel
AppleScript Engineering _______________________________________________
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