Re: Passing *possible* variables to a handler
Re: Passing *possible* variables to a handler
- Subject: Re: Passing *possible* variables to a handler
- From: has <email@hidden>
- Date: Sat, 13 Jul 2002 12:00:14 +0100
Arthur J. Knapp wrote:
>
While I was responding to your posting, I discovered something
>
interesting:
[...]
>
ie: script objects are perfectly happy to accept records as their parent:
Script objects are happy to accept pretty much any object as their parent.
Your timing is pretty good, Arthur: I was playing about with this recently,
looking for ways to provide a wrapper for lists that'd allow O(1) access
times. Essentially the same trick as Serge and others were discussing on
the macscrpt list a couple months back, except in OO form.
======================================================================
on wrapList(theList)
if theList's class is not list then error "Not a list."
script
property parent : theList
on getItem(itemIndex)
return parent's item itemIndex
end getItem
on getItems(index1, index2)
return parent's items index1 thru index2
end getItems
on setItem(itemIndex, newValue)
set parent's item itemIndex to newValue
end setItem
--[any other methods here]
end script
end newList
--TEST
set wrappedList to wrapList({})
--populate the list with N items
repeat 1000 times
set wrappedList's end to 0
end repeat
--measure access times
--(uses PrecisionTimer osax)
set a to install precision timer
repeat 100 times
set wrappedList's item 1 to 9
end repeat
set a to stop precision timer a
set b to install precision timer
repeat 100 times
wrappedList's setItem(1, 9)
end repeat
set b to stop precision timer b
{a, b}
--> {0.012972, 0.008755} -- 10 items
--> {0.066991, 0.008826} -- 100 items
--> {0.644565, 0.008568} -- 1000 items
======================================================================
(Dig that dynamic behaviour! AS's ability to subclass objects on the fly
is just sooo neat...:)
Unfortunately, AS doesn't allow users to overload operators so there's no
way to do this properly by overriding 'text n thru m', '&', etc, which
would make the whole thing transparent and a simple shoe-in for existing
code. The new object doesn't respond to the concatenation operator at all,
which is a pain: you'd need to provide your own 'concat()' method and
direct folk to use that instead. And you only get the performance benefits
using the custom methods I've added, obviously, so you'd still need to
change your code in the places where the speed is needed.
Still, it might be slightly neater to use something like this rather than
mucking up your handlers with:
script speedKludge
property __theList : theList
end script
tell speedKludge
get its __theList's item foo
[etc...]
stuff in order to speed them. Plus it's a bit more foolproof: it's easy to
write something that you think will work as above but which still gives
lousy O(n) performance.
All of which would cease to be an issue if the AS team bite the bullet some
day and 'fix' list behaviour to give O(1) performance in the first place
[1]. But <sigh> sometimes it feels like our lives must be devoted to
kludging around the hacks for the misapplied patches for the incomplete
features of what would otherwise be a Really Swell Language...;p
has
[1] Yes, I am aware of the amount of work this'd involve, but AS's various
performance problems are going to have to be tackled sooner or later. The
only safety/stability problem I can recall is that there's a greater need
to explicitly evaluate values extracted from lists (I've a script on my
site demonstrates this), but implicit vs explicit evaluation in AS is
another issue that needs thrashed out anyway [i.e. there's already various
things that don't work properly unless the user adds an explicit 'get', but
keeping this stuff right is supposed to be AS's job, not the user's].
--
http://www.barple.connectfree.co.uk/ -- The Little Page of Beta AppleScripts
_______________________________________________
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.