Re: Text items
Re: Text items
- Subject: Re: Text items
- From: kai <email@hidden>
- Date: Thu, 18 Jan 2007 02:10:28 +0000
On 17 Jan 2007, at 14:07, Adam Bell wrote:
I've taken the liberty of explaining Kai's clever script:
Thanks, Adam. After the numerous attempts to iron out a few basic
wrinkles last night, I appreciate the help in teasing out some of the
techniques involved. :-)
If I may, perhaps I can just add one or two footnotes:
to strip_extensions from q to e -- q is the original list, e the
occasional terminator
script o
property l : q -- casting a list as an embedded script
property assures that the list object is kept in memory for rapid
manipulation. Great speeder-upper for long lists.
Indeed. When accessing longer lists, one of the most effective
performance-enhancing methods is to introduce a referencing
technique, such as the 'a reference to' operator, or (better still) a
script object's property. (If the list is represented by a property
at the top level of the main script, qualifying the property
reference with 'my' or 'of me' also works.)
It's worth noting that, for short lists (of less than a dozen or so
items), initialisation of the script object can incur a small time
penalty (usually imperceptible at those levels). Beyond that, the
benefits become increasingly apparent.
There's also something else at play here, which might be worth a
mention. Through a feature known as data sharing, two or more
variables can share the same list, record, date or script object. So,
in the 'strip_extensions' handler, when we change the value of an
item in script object o's property l, we're also modifying the same
item in the handler's variable 'q'. In addition, since the same data
is shared by the calling statement's variable 'names1', the change is
reflected there, too. That's why there's no need to return the value
of the modified list at the end of the handler.
This might help to demonstrate the principle:
-------------------
on current_values()
set text item delimiters to return & tab
set curr_val to my names1 as string
set text item delimiters to {""}
display dialog "Current values of names1: " & ¬
return & return & tab & curr_val
end current_values
to demonstrate_data_sharing(q)
script o
property l : q
end script
current_values()
set first item of my names1 to "One"
current_values()
set q's item 2 to "Two"
current_values()
set o's l's last item to "Three"
current_values()
end demonstrate_data_sharing
set names1 to {1, 2, 3}
demonstrate_data_sharing(names1)
names1 --> {"One", "Two", "Three"}
-------------------
considering case -- don't want opposite case of e
As well as minimising any confusion between upper/lowercase variants
of a substring, a considering case statement can also virtually halve
the time it takes to execute text comparisons. (While the performance
boost from tweaks like this may be imperceptible for the occasional
comparison, it can add up in repeat-intensive situations.)
tell text item 1 of o's l's item i to if it ends with e then
-- text item 1 of the list; the part before the extension's "." Is
e in it?
Here, the 'ends with' containment operator is used in favour of
'contains' for specific focus. Again, concentrating the comparison
also tends to be a tad faster.
Incidentally, if there's a possibility of filenames containing an
extra ".", this part of the routine could easily be generalised
further within the repeat loop by replacing:
tell text item 1 of o's l's item i to if it ends with e then
with:
-----------
tell text 1 thru text item -2 of o's l's item i to if it ends with e
then
-----------
While we're on the subject, one syntax form that may sometimes seem
unclear is the 'tell <some object>' construct (sometimes used for
brevity and/or a slight speed bump). This specifies the given object
(reference, value, whatever) as the default target; the object to
which commands are sent when they don't include a direct parameter
(such as "<some object> of <some target>", or "<some target>'s <some
object>").
Instead of saying something like...
-----------------
if <some object> of <some target> is <some value> then <do something>
with <some property/element> of <some object> of <some target>
-----------------
... we might use a variable, to avoid repeated references:
-----------------
set <some variable> to <some object> of <some target>
if <some variable> is <some value> then <do something> with <some
property/element> of <some variable>
-----------------
Alternatively, we could use a tell statement to define the target,
referring to it subsequently using the AppleScript variable
'it' (specifically defined for this purpose).
-----------------
tell <some object> of <some target> to if it is <some value> then <do
something> with [its] <some property/element>
-----------------
In many cases, the [its] is implicit and doesn't need to be specified
- although, to avoid ambiguity, some circumstances may require the
explicit form. (This is exemplified by running the statement: tell
(current date) to {hours, its hours}).
So, while this form of syntax may seem a little curious initially, it
becomes much more intuitive with use. :-)
---
kai
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/mailman//archives/applescript-users
This email sent to email@hidden