Re: Libraries and effiency
Re: Libraries and effiency
>> Why an Osax rather than an FBA?
>
> Here's what I wrote in the previous reply. Sometimes it's good to read the whole story :-)
Silly me, I stopped where it said "end of story". But there was more! : )
>> Speed counts in the video world.
No doubt. I think I get it now. Your software is faster as an Osax than a FBA (I didn't realize Osax were faster than apps), and your strategy to avoid terminology conflicts is to use terms that don't fit with the natural language metaphor, but that others are less likely to use.
And that works for you.
In my case, I prefer FBAs to Osax and I pretty much avoid software that breaks AppleScript's English-like language. I know that's not true for everyone but it is for me.
As far as libraries and efficiency go, I probably could use and should use libraries for some of my scripts. Plus, I use Script Debugger and it has a built in method of including handlers in scripts, which I also could/should use, but I don't. I mostly copy and paste (or use the SD snippets function) which is what I think most appleScripters do.
For me, I find it easier to debug and maintain single flat scripts.
If I find a bug or make a change in a handler I use in a number of scripts, then, yes, I may have to fix that handler in every one of those scripts. But, since I pretty heavily test each script before I use distribute it, I'm fairly confident they'll function even without the change. If that handler was in a library, I only have to fix the handler in one place, but I'm going to test each of those scripts to make sure the change doesn't break something else. And if I don't remember each script the handler is in, then suddenly a working script somewhere may stop working, so I don't see that big of an advantage for appleScript libraries.
Another issue is that none of the library loading systems I've looked at are intuitive or transparent. I know that's not important to everyone but it is to me.
I like to look at a sample script or a dictionary and know what each command does. I like being able to read a script months or years after it was written and understand exactly what each line is doing. I don't get that with the library loaders I've seen.
I have one system I've used where I store all my handlers in a stay open app, and launch and call then quit that from the main script. Very kludgy, but It works, I know what it's doing and it's easy to debug. I prefer that to any of the library loaders I've seen. It's more intuitive.
I've also used applescript's load script and run script functions and those work fine for me too.
I'm just wondering if there's not a lot of time and effort going into fixing something that's not terribly broken or building something that's not really wanted.
As for how I'd like to call handlers in a library, I'm no Cal Simone, but ...
Maybe I'd use a command like:
using handlers from mySpecialLibrary
end using handlers
or
tell me to use script library mySpecialLibrary
-- where the variable mySpecialLibrary specified a path to a library
or
Maybe a command like:
use script library "MyFinderHandlers"
--where MyFinderHandlers was the name of a file located in an appleScript library directory.
Or
tell application "AppleScript Library"
HTH,
ES
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden