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: Nigel Garvey <email@hidden>
- Date: Mon, 12 Apr 2004 15:10:12 +0100
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,
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.
>
By comparison:
>
>
set x to missing value
>
set y to a reference to x
>
get y's contents
>
--> missing value
>
>
...but 'set' still recognizes that here:
>
>
set x to missing value
>
set y to a reference to x
>
set y's contents to anything
>
>
...you're not trying to set 'missing value' to 'anything'.
That's true. When you mention a variable or a reference as the direct
object of a 'set' command, you mean it in its own right - something
separate from the value you're assigning to it. When you use it in an
implicit or explicit 'get', it's its value that's implied and returned.
set x to missing value -- 'x' implies the variable
get x -- 'x' implies the value of the variable
The value of y in your example is not a reference to 'missing value', but
a reference to the variable x, so:
get y -- get the value of y
--> x of <<script>>
get y's contents -- get the value of x of <<script>>
--> missing value
set y's contents to anything -- set x of <<script>> to anything
It can get a bit confusing at times!
>
Even if it did work, though, it would only be useful if applications
>
could return property references. Have you ever seen a program that
>
allowed this:
>
>
tell app "Finder" to get name of files 1 thru 2 of f as reference
>
--> {name of document file "hello there" of folder "Temporary Items" of
>
startup disk of application "Finder", name of document file "hellother"
>
of folder "Temporary Items" of startup disk of application "Finder"}
Just imagine trying to explain its use to newbies - or even to understand
it oneself. ;-)
>
>> tell application "Finder"
>
>> set name of first file of folders 1 thru 2 of f to {"hello", "there"}
>
>> end tell
>
>
I'm considering it as a matter of context. First, application class
>
properties usually aren't lists. Second, even in the cases where they
>
are, the scripter, developer, and the 'set' command itself would, in
>
most applications, be able to tell by context what to do. Now, some
>
people don't like too much context-based behavior, but how much is too
>
much? I happen to like context, and AppleScript seems pretty context
>
sensitive.
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. But I'm wary of the potential
pitfalls in what you call "context-based behavior", which translates for
the scripter as "context-based meaning".
As things stand at the moment, there's a basic logic to the 'set' syntax
of the language:
set this to (get the value of) that
This is still true for "bulk" settings in applications:
tell application whatever
set thisVariable to [the value(s) of whatever's covered by this
reference]
-- or:
set [whatever's covered by this reference] to thisValue
end tell
As I noted above and in my previous post, there's a convention in written
AppleScript where several things can be set in parallel in one
instruction:
set {this, this, this} to {that, that, that}
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. It's something the compiler understands and can generate code for,
and it's consistent because it happens at the AppleScript language end.
But the contextual system you're proposing involves having a single
reference on the left and a datum of any value on the right:
>
tell application "Finder"
>
set name of first file of folders 1 thru 2 of f to {"hello", "there"}
>
end tell
The reference 'name of first file of folders 1 thru 2 of f' doesn't
return a value to the compiler; it's simply a reference to be compiled
into the instruction to the application. So it's the application, rather
than the compiler, that would have to interpret the context. "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."
Nice little project for someone. ;-)
NG
_______________________________________________
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.