Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
- Subject: Re: (2 of 2) Application Scripting Question - Theoretical? (was Re: Technote 2106 is da Bomb)
- From: Michael Terry <email@hidden>
- Date: Mon, 12 Apr 2004 13:54:22 -0700
OK, Nigel, I think I've finally got the
ellipses-continuing-from-inline-code-example construct down. They say
that imitation is the sincerest form of flattery, you know. However,
Marilyn vos Savant says that it's not, because it implies you think the
person's greatness can be copied. Of course, you shouldn't take it like
that!
On Apr 12, 2004, at 7:10 AM, Nigel Garvey wrote:
Michael Terry wrote on Sun, 11 Apr 2004 13:42:49 -0700:
On Apr 11, 2004, at 8:17 AM, Nigel Garvey wrote:
In the case of:
set contents of {a, b} to {"hello", "there"}
... the compiler doesn't recognise this as a setting by list. It sees
an
instruction to apply the 'contents of' code to {a, b} and to set the
result to {"hello", "there"}. At run time, the 'contents of' code
returns
a *list* {3, 4}, which obviously can't be set to anything.
Well, that's what does happen, but wouldn't it have been logical for
AS
to recognize it the other way?
I don't know about logical, but it might be convenient sometimes. :-)
The
problem is that the compiler would have to be able to see in advance
that
the result of 'contents of {a, b}' would be a list containing
variables,
It doesn't sanity check single assignment, so why would it have to
sanity check multiple assignment? The compiler doesn't block this, for
example:
set 7's contents to 7
As there, it would simply trust that you knew what you were doing. This
construct:
set contents of {a, b} to {3, 4}
... can't have any other meaning, right? AS should try to do what I
think it should; if it fails it fails, but failure wouldn't be AS's
fault.
and that therefore, in the context of the line, this list should not be
interpreted as a list but as the written convention for setting several
variables in one line.
But what we've never realized before, because it takes hair-splitting
examinations like this one to tease these things out, is that the list
on the left hand side of a multiple assignment is not just a
convention. It's really a list:
set {x, 7} to {3, 4}
--> {3, 4}
If it were just a convention to set variables--'set a to 3' and 'set 7
to 4' in parallel--then the 'set 7 to 4' part would raise an error.
It's not the first time AS has let me work with a list literal in the
code:
tell {}
repeat 5 times
set its end to 1
end repeat
return it
end tell
--> {1, 1, 1, 1, 1}
Look, if even this doesn't fail:
set {1, 2} to {3, 4}
... then why should this? (supporting code omitted):
set contents of {a, b} to {3, 4}
If we write:
set a to 1
... I don't think it's fair to say that 'a' is just a convention there.
It's a literal reference, 'a of <<script>>'. If we write:
name of first file of app "Finder"
... that's a literal reference, and we can also put it in a variable:
set a to ref name of first file of app "Finder"
--> name of file 1 of application "Finder"
The result looks exactly like it would if we typed it in the code. I'd
think it oddly inconsistent that for the one case of multiple
assignment, the left hand side of the 'set' wasn't a real AS type.
I'd still have to say this is inconsistent, possibly buggy behavior,
but it's your turn. :)
I myself am a great fan of what I call "bulk actions", such as were
possible with pre-X versions of the Finder. They made possible some
very
fast, compact, and fun-to-write scripts.
Could you give an example or two, just for fun? I didn't script much
pre-X; I'd like to know what I'm missing.
This is not setting one list to another, it's just a written convention
for setting the individual thisses on the left - which must all be
variables or references - to the corresponding thats in the list on the
right. Following standard 'set' practice, the result *is* the list on
the
right.
Can you think of a way to show that the result is really the list on
the right, and not, well, the result? I couldn't come up with one. I
think one of my examples above suggests otherwise, but there's also the
possibility that it's a bug in AS. In whichever case, AS is behaving
inconsistently.
"If this
application supports contextual interpretation, and if it supports it
in
the way about to be described, and if the supplied reference refers to
more than one property, and if the supplied value is a list or is a
reference that returns a list when got, and if none of the referred-to
properties can ever take a list value - except of course if there are
lists within the list, and if there are the same number of properties
referred to as there are items in the list, then set each of the
properties in turn to the corresponding values in the the list, hoping
that the properties have been identified in the same order as their
proposed values in the list. Otherwise set all the properties in turn
to
the entire supplied value."
Ha ha. ;) That makes it sound very hard, but of course you can make
anything untrivial sound very hard when you explain it like that. The
truth is, most of that will be required for an alternate command, too,
but surely it's worth having. Anyway, if even the best scripters are
resisting the idea, I won't promote it.
You do think the 'distribute' command idea is a good one, at least,
right? I think it's a great idea.
Mike
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.