Re: Passing *possible* variables to a handler
Re: Passing *possible* variables to a handler
- Subject: Re: Passing *possible* variables to a handler
- From: "Arthur J. Knapp" <email@hidden>
- Date: Sun, 14 Jul 2002 13:09:14 -0400
>
Date: Sat, 13 Jul 2002 12:00:14 +0100
>
From: has <email@hidden>
>
Subject: Re: Passing *possible* variables to a handler
>
Arthur J. Knapp wrote:
>
> 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.
Yes, I posted a wrapper something like this as well.
>
on wrapList(theList)
>
script
>
property parent : theList
>
>
on getItem(itemIndex)
>
return parent's item itemIndex
>
on getItems(index1, index2)
>
return parent's items index1 thru index2
>
end getItems
>
--[any other methods here]
>
set wrappedList to wrapList({})
>
--populate the list with N items
>
repeat 1000 times
>
set wrappedList's end to 0
Now THAT is COOL !!!
So all list "properties" can be inherited by a script object, ie:
wrappedList's some item --> random member of list
wrappedList's reverse --> reversed list
You would get the best of both worlds, a wrapped list to which you could
both add methods and treat as having list properties.
>
--measure access times
>
--(uses PrecisionTimer osax)
>
set a to install precision timer
>
repeat 100 times
>
set wrappedList's item 1 to 9
>
set b to install precision timer
>
repeat 100 times
>
wrappedList's setItem(1, 9)
>
{a, b}
>
--> {0.012972, 0.008755} -- 10 items
>
--> {0.066991, 0.008826} -- 100 items
>
--> {0.644565, 0.008568} -- 1000 items
Right, so item-access speed is comparable to typical Serge access, ie:
there is no speed payoff in using:
wrappedList's item x
over
wrappedList's getItem( x ).
>
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.
Right:
script o
property parent : {1, 2, 3}
end script
{0} & o --> {0, <<script o>>}
o & {4} --> {<<script o>>, 4}
I tried a goofy experiment, but to no avail...
script o
property parent : {1, 2, 3}
property class : list -- ;-)
end script
o's class --> list
{0} & o --> {0, <<script o>>}
o & {4} --> {<<script o>>, 4}
However, there is always the "contents" syntax, which would make
it no more difficult to work with than a repeat-with-var-in-list
variable:
{0} & o's contents --> {0, 1, 2, 3}
o's contents & {4} --> {1, 2, 3, 4}
Of course, you're not getting a new wrapped-list in return...
>
... 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
Hey, that's not a personal attack, is it? (I've been known to use double-
underscores to indicate "internal" methods). ;-)
>
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.
I agree, a wrapped list with direct syntactic item and "property" access
is a seriously cool idea. (And just on the q.t., it is very OO). :)
I also like the possibilities this brings up for wrapping other object-
like data types:
on newDateTime(_optional_date_)
if (_optional_date_'s class = date) then
set d to _optional_date_
else
set d to current date
end if
script DateTime
property parent : d
on day0() --> silly method example
return ("0" & my day)'s text -2 thru -1
end day0
end script
return DateTime
end newDateTime
set thisDay to newDateTime(date ("" & "4 July 2002"))
thisDay's day --> 4
thisDay's day0() --> "04"
P.S. Has, I love you, I want you, let's run off together to some tropical
AppleScript island and live out our days in object-oriented bliss...
;-)
{ Arthur J. Knapp, of <
http://www.STELLARViSIONs.com>
a r t h u r @ s t e l l a r v i s i o n s . c o m
}
_______________________________________________
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.