On 19. jan. 2010, at 19.25, Stockly, Ed wrote:
I don't like Script Objects because they're a pain to debug.
Same..
The only reason I use them (and I don't use them that much) is that in some
cases they dramatically reduce the execution time for specific tasks.
This is something I've not always considered, and I think with some scripts that take a long time to compile/execute, it's worth the hassle. I used them in Classic because of the built-in limits on the size of
scripts, but that's no longer an issue.
It isn't? I had a script running in OSX that was getting Stack overflows, reducing the code actually the issue.. Or did I miss something?
My scripting life is much simpler
now as a result. My solution for reusable code is to reuse handlers and
make long scripts and those run just fine.
yes, re-using code, and making handlers dynamic enough to be re-used is incredibly valuable, on so many levels, debugging is always alot easier, not to mention it cleans up your code to the point where you don't need to do things like load scripts or make objects.
I'm also interested in what other AppleScripters think about them.
I only replied because you said you wanted to know what people think.
I like to think that I'm on the lower end of an being called an "Advanced" applescript user. My job consists of doing about 60-70% applescript work. I can usually solve my applescript needs with clean code, writing relatively simple to read code. I find using objects can in many ways over-complicate things if they are not totally necessary.
To me, it makes alot more sense to keep all your handlers in the same place.
In saying that... The only time I've ever used an "object" or in this case "load script" is where I store all my handlers and global values in one script, then use other scripts which call on those global properties, and global handlers.
That way code can be re-used for many scripts and any hard coded logic remains in the one place. And fixing a handler once can solve the problem for many scripts.
|