Re: max script size
Re: max script size
- Subject: Re: max script size
- From: has <email@hidden>
- Date: Thu, 27 Mar 2003 01:03:03 +0000
Simon Brown wrote:
> Most
solid approach I've found is to pass the main script into the
subscript, either as an extra parameter to the handlers that use it,
or in a separate operation, stuffing it into a property in the
subscript where it can be referenced by the subscript's handlers.
Just catching up a few missed days.... this post is like a Eureka moment,
nearly...
I've just done a little test of your concept, as in passing (foo, bar, ME)
as parameters to a subscript. Works luvverly, as a very concise way of
giving access to get (or set) current values of every property/variable of
the main script without using globals.
Yes.
Though, as with a single script, you generally don't want more global
state kicking around than necessary, nor do you want to be accessing
properties from every point in your script. Those are design issues
though (state is evil; coupling and cohesion), not mechanical ones.
I am haunted by a feeling that it is somehow a cheat though...
Not at all.
I just mean
that while it is fantastically good shorthand for passing all the current
values I thought it would use more memory by passing the whole script rather
than passing an array of relevant variables*.
No, because AppleScript only copies data passed as arguments to a
command when it's being sent via an AppleEvent (i.e. to an osax or to
another application).
If you're only passing a few values, it's probably better to pass
them individually than send in the entire script and dig them out
later. But again, that's a design issue: it makes it easier to see
what's going on in the code.
*Hmm.. Just checked a bit more and it seems that passing "Me" is
functionally equivalent to "a reference to Me", i.e. not a copy of the
script but a 4 byte??** reference to the current script (as an object).
Not exactly, as a reference to an object isn't the same as the object
itself. Only time you might want to use a reference is when using the
copy command in OOP; rest of the time there's no advantage in it and
it's just one more level of dereferencing that has to be done.
[snip code]
I take it that the above is an example of what you call "dynamic binding"?
You may be getting confused. The difference between static and
dynamic binding is _when_ you bind (not how stuff gets passed around).
Static binding = compile-time binding:
property MyLib : load script (alias "path to MyLib")
Dynamic binding = run-time binding:
property MyLib : missing value
on init()
set MyLib to load script (alias "path to MyLib")
end
on run
init()
...
end
on open x
init()
...
end
Here's how I'd do a static binding where a main script binds a
sub-script and the latter later needs access to the former's
properties and handlers:
Main script:
property subScript : init(me) of (load script (alias "path to subScript")
Sub-script:
property _mainScript : missing value
on init(mainScript)
set _mainScript to mainScript
return me
end
It seems like such a powerful programming technique that it _MUST_ have some
dangers/drawbacks..... just something to do with the concept of having such
good access to the parent object, the _Main_ routine, at runtime, makes me
think there must be some associated gotchas?
Used well, it's a valuable tool for organising and managing code in
medium-to-large projects. Used badly, it's just one more ingenious
way to tie yourself in impenetrable knots. But there's plenty other
ways you can do that: globals everywhere, 100-line handlers (or no
handlers at all), misleading variable names, convoluted flow control,
not accounting for potential error conditions, deploying
untested/untestable code, etc, etc, etc.
Basically, you're getting into real Software Design territory. The AS
literature explains how the language works but doesn't touch on any
programming theory (basically it says "this is a variable, this is a
command; go knock yerself out, kid"). Fine when writing 5-10 line
scripts, but not nearly enough knowledge for coping with scripts that
are hundreds or thousands of lines long. If you want to learn some
serious programming skills, you'll have to look to general computing
resources. I found Code Complete from Microsoft Press good and easy
to read when I was in need of a clue. There should also be plenty of
material online; though knowing where to start, what to look for, and
discerning good info from bad may be hard - maybe the professional
programmers could make some recommendations?
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.