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: Mon, 15 Jul 2002 10:42:38 +0100
Arthur J. Knapp wrote:
>
> on wrapList(theList)
[...]
>
> 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.
Pretty much. I wish this stuff were seamless like it is in, say, Java. This
approach is _much_ less convenient, and I wouldn't get too carried away
with it too quickly, but it may have its uses, e.g. for kludging around our
favourite list access problems with a minimum of disruption.
>
> {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 ).
Mmmm? No, the former gives you O(n) behaviour as usual. Only the latter
gives the desired O(1).
[no concatentation, etc]
>
{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}
I'd tend to provide methods for this sort of stuff, rather than encourage
the user to go poking around in the object's internal state like this:
======================================================================
on concat(secondList)
return my parent & secondList
end concat
on asList() --[coerce to list]
copy my parent to plainList
return plainList
end asList
======================================================================
Admittedly, we're already letting them poke around with stuff like "set
listObj's end to...", but that sort of thing behaves pretty much as
expected - besides, this thing is intended for user convenience, not its
formal OO design. But you'll notice my asList() method above returns a copy
of the list, not the list itself: that's important if you want to avoid
potential data-sharing woes later. I'd be quite clear about documenting
when direct access is acceptable, and when the methods should/must be used
instead.
Oh, and comparisons don't work the same as they do for native lists either,
though you probably realise that already.
>
> 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). ;-)
Mmmm? Not at all. I use single underscores for indicating private
methods/properties, and a double underscore for <cough> protected ones.
(Using a leading underscore to indicate "private" seems to be a convention
for languages that don't have built-in support for it.)
>
> 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). :)
Certainly more OO than the previous approach. Pretty bogging compared to
Java and friends though.
>
I also like the possibilities this brings up
[Uh-oh, here he goes again... <smak> Bad Hamish! Not before Arthur's taken
his medicine.;p]
>
for wrapping other object-
>
like data types:
>
>
on newDateTime(_optional_date_)
Well yes, but remember what I said already about this stuff not being all
that good as a direct replacement for existing data types. Use in
moderation, and make sure you document why you've done it and where
behaviour differs from the expected. It may still be better to roll your
own objects from the ground up in 99% of cases, hiding state completely and
providing access via your own methods only. Then there's no chance of
confusion over how the object should and should not be used.
OTOH, AS is such a weeeeird language for doing OOP in, I doubt there's much
we could do to make it any weirder. (Please don't take that as a challenge,
however.;p)
>
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...
Just let me pack my sun block...
:)
has
--
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.