It grows quickly in the new script libraries folder, and soon it is like it used to be with the old script objects we used to load. You’ll either end up with a zillion small script objects, or some big ones, containing far too much for the normal usage of that library.
Well, maybe it is time to think of something new. In java they have a pacackage system where the different levels are separated by dots.
I have been stealing a little from this scheme, and I ended up with top level triplets like app, and text, when it is concerning that specific class of AppleScript Datatype, but I also have added top level triplets for “sys” which are commands for debugging, and IO which relates to input output.
My former library named Output, can now be named io.console, or it can be put into sys.debug.textedit.
A handler for taking text and filenames from two files and showing them in Filemerge can be named app.filemerge.showtwo.
A handler for locking a file with finder can be named app.finder.lockfile
You get the idea. The name of the the classes here are not important, the idea is to have something consistent, that eases the use, as the libraries grow.
I want to mention more specifically former library named Output, can now be named io.console, or it can be put into sys.debug.textedit. Now say I don’t want to have logging to text edit anymore, but want to use Console instead. Then I can look at the former library as a protocol defining the methods for achieving functionality. Then I can make a new library, that implements the same calls, maybe some of them just stubs, that do nothing.
I can then change the reference to my first library (the use ouput : script “sys.debug.textedit”) to the new one (use ouput : script “sys.debug.console”), recompile, and then switched all the log output to the Console.app.