Re: Scope
Re: Scope
- Subject: Re: Scope
- From: Paul Berkowitz <email@hidden>
- Date: Sun, 15 Dec 2002 10:48:12 -0800
[This got bounced back once for being too long, so I'm sending it in two
parts. It's still long.]
On 12/15/02 7:34 AM, "Paul Skinner" <email@hidden> wrote:
>
Paul B,
>
I'm glad that you solved your problem and I'm sorry if you felt I was
>
being obtuse or critical.
"Tangential" might be a better word. Telling me, after I've spent several
months on a complex project that works very well aside from one, almost
trivial, error that I should start all over with a different design, is not
what I'm looking for at this point. I probably would do something different
next time, but - for this time - I just want to find the problem and solve
it. I was hoping that someone out there had run into the same thing and knew
what to do about it. In fact, Emmanuel's answer and suggestion did just
that, but I didn't fully understand his explanation which was not quite
complete and assumed I knew what he was doing, which I didn't. A private
email from has explained Emmanuel's method (see below), and then had a very
detailed plan for a different type of design. More below.
>
I'm developing a project that will handle hundreds of handlers for
>
multiple scripts and this problem seems to be pertinent. I also have an
>
error handler that gathers data from within subroutines and returns
>
them to the user.
Yes. You probably should do it one of the two other ways, not the way I did
it. I did not plan to have a second script, although if I had known how huge
this project would become I would have started that way from the beginning.
I had one script, but clearly organized into two main sections, plus a run
handler, "a FinishOff" handler, an error handler, a quit handler, and a
group of "utility" handlers. Aside from the utility handlers (removing items
from lists, making large lists with more than 4060 items from test by tids,
that sort of thing), each of the two halves is completely self-contained.
each as a sort of master "controller" handler that directs operations for
its half. Within each half there's also a separate subsection, also
self-contained, with its own subcontroller handler.
So, when I hit the bug in AS 1.9 that prevents script compilation when you
get to about 140 KB source text, it was very easy to break the script into
two halves and load the second script when needed. I also duplicated the
utility handlers into the second script so that I didn't have to go back and
forth. Because of the need to have a lot of information available whenever
an error resulting from corrupt data occurred, and also because of
limitations imposed by using a progress bar via 24U Appearance OSAX with
repeat loops, which again requires lots of globals to be directly available
at all times, I ended up with more properties and globals than I would like.
In order to be able to pass all the values I needed to script B and not have
to rewrite it all, I had to define all of them (I thought) as properties in
group B. So I gave them all 'missing value', then passed all the current
values from script A to script B before calling any handlers in script B.
Some of them are "running totals" which have to passed back at the end. in
fact there are only six variables which have to passed back to script A: 4
running totals being incremented on repeat loops, one boolean variable which
ight change from false to true during script B, and that one list (of
specific data for any item that errored) which might have items appended to
it. It's when NO items need to be appended to this list, so that the
variable representing the list never once gets called, that returning the
variable without 'my' apparently returns the initial 'missing value' instead
of returning the list sent by script A. Simply returning 'my' with the
variable forces it to evaluate the correct value which it otherwise doesn't
seem to notice. it's as if it ignores its own context and goes back to the
saved copy of itself top get the initial value. That shouldn't happen.
that's the bug, and no, it's not easily replicable. It doesn't happen with
short example scripts at all, only with immense scripts. (Each of script A
and script B is now up to about 90K.)
OK. I could see that Emmanuel's suggestion implied that I was passing a
script object from script A to script B. But I wasn't, so I didn't know what
to make of his suggestion. has explained that a loading script (A) can load
ITSELF into script B, so then you don't need to redefine any properties.
They all become properties of script B. I would do this do this by including
a parameter such as A, or - more clearly - mainScript in the controller
handler in script B I'd be calling. There it would look like
on ControllerHandler(mainScript, var4, var5)
--do stuff with mainScript's properties
--call other handlers, include mainScript every time
end ControllerHandler
Back in script A, you'd call that handler via
set f to load script alias "path:to:Script B"
set {var1, var2, var3} to f's ControllerHandler(me, var4, var5)
You can load 'me' into script B that way. What Emmanuel was warning me was
that in script B I should always refer to 'mainScript's var3', never just
'var3'. But I didn't know what he was telling me.
Again, at this point, even to use this method, I'd have to add
'mainScript's' hundreds of time to my 3000-line script B. If I tried that at
this point, I'd be sure to omit it 150 times, and I'd still be sitting here
debugging two months from now. So I'm not going to do it since I found my
simple solution. But that's because my script started as one and then split
into two. This would be a good way to do it if planned out.
But has has (there we go again ;-)) a completely different, totally OOP
modular way of doing it, which certainly is very clearly organized. If you
are writing a script for clients who might be maintaining the script
themselves, you'd definitely want to go that route. I will forward you has's
message, and if there is general demand I'm (or has) can post it here too.
It's very long.
[...to be continued]
--
Paul Berkowitz
_______________________________________________
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.
| References: | |
| | >Re: Scope (From: Paul Skinner <email@hidden>) |