Re: Newbie Question: Script Objects (2)
Re: Newbie Question: Script Objects (2)
- Subject: Re: Newbie Question: Script Objects (2)
- From: has <email@hidden>
- Date: Tue, 18 Feb 2003 03:33:09 +0000
Simon Brown wrote:
Martin Crisp <email@hidden> wrote:
Properties are inherent to the script - if they change the change
'sticks' (provided the script completes) until it is recompiled.
Please see my earlier post in reply to Andrew Oliver (Mon, 17 Feb 2003
00:22:52 +0000) with example showing that properties of Script Objects (as
opposed to scripts) DO reset every time the script is closed and reopened -
or do you mean the script is recompiled every time it is opened, even if no
changes are made?
Opening a script in a script editor recompiles it and thus resets its
state at that point. That'll be what you're seeing.
Another complication I've thought of is that I hadn't really considered the
implications of script object names being variables. [...]
See other post.
To summarise WHY I want to use a script object (for handling time-range
calculations):
1) I want to reuse it in a variety of scripts without having to add globals
or properties at the root level of the scripts that only apply to the script
object. This is part of my modular design philosophy.
Fair enough. Less global state you've got running around a big
complex script, the better for your sanity. Plus you can do the reuse
thing by hiving such modules off into standalone library files that
you can then bind to scripts that need them using the load script
command (much better than copy-n-paste "reuse").
2) I want the properties of the script object to be reset every time the
script apps containing or loading it are launched & run but to persist
outside the duration of calls to the handlers in the script object itself
(as one or more of the routines within it may be called many times during
the execution of stay-open script apps).
Define the prototype object, and clone it to a property at runtime:
-- properties
property foo : missing value
-- prototypes
script _FooPrototype
on hello()
say "hello"
end hello
end script
--
on init()
copy _FooPrototype to foo
end init
on run
init()
foo's hello()
end run
Or instantiate the object at runtime using a constructor function and
stick it in a property:
-- properties
property foo : missing value
-- constructors
on _makeFoo()
script
on hello()
say "hello"
end hello
end script
end makeFoo
--
on init()
set foo to _makeFoo()
end init
on run
init()
foo's hello()
end run
Hope that makes some kind of sense. I've created classes in Visual Basic to
perform similar functions, but if my programming strategy is way off please
let me know.
You've probably worked out already that Script objects <> VB classes.
AS is like JavaScript or Self: prototype-based instead of traditional
class-based. Rather than defining classes and then instantiating
objects from them at runtime, just define the objects themselves and
clone them as necessary, or churn them out using a constructor
function.
Alternatively, if I'm reinventing the wheel and someone has
already done a neat job of this or written an OSAX, I'd love to see it.
Try my website. I've been doing modular and OO programming in AS for
the last year or so, and a bunch of libraries I've written are posted
there (both procedural and OO). Some of the early stuff is a bit
hoary, but might be useful by example. Also take a look at ASLoader,
a dynamic library/support script loader that can take care of tedious
inter-file bindings for you.
has
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of 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.