Too many Handlers? Move to Script Library? Modifing Other Libraries?

Hi everyone,

So as my own script grows an I come up with my own handlers,
and find other handlers to use online.
and find ways to either help interface to other libraries.
Here are my questions:

How many Handlers is too many?

When should I consider moving them to my own custom library?
addvantages / disadvantages?

When creating my own custom library what thing should I consider?
Such as possibly going back and renaming things so that they are more
“general” description rather than for my own code? And I guess probably
adding comments to help detail things?
EDIT: and I’ve just realized that these script library’s can have their own dictionary
(I have no idea how these are created)

Should I consider sharing these libraries? If so what’s the best way/place?

When using many of the great libraries that are out there, I find I often
need to come up with ways to help to prepare data to send to them.
Often I come up with little handlers to help me do that.
What’s the best way to this? Should I add them to the library or keep them serperate?
Should I share these “add ons” with the library creator and or community?

thanks

Can’t have too many, only have too few. If an handler is doing more than 1 tasks the handler is doing too much. When following Google, NASA or any high disciplined programming guidelines for safe programming, the following handler is already too long:

on stringReplace(haystack, needle, replace)
	tell AppleScript
		set oldTIDs to text item delimiters
		set text item delimiters to needle
		set TIs to every text item of haystack
		set text item delimiters to replace
		set newStack to TIs as string
		set text item delimiters to oldTIDs
	end tell
	return newStack
end stringReplace

The reason why the handler above is considered too long is because the handler is performing 2 tasks. The handler splits a string using an separator and joins an array into a string using an separator. Also if you would write an handler for splitting or joining a string using a separator there would be redundant code which indicates your handlers are too big. The correct code would look much more similar to this:

on stringReplace(haystack, needle, replace)
	return join(split(haystack, needle), replace)
end stringReplace

on join(lst, sep)
	tell AppleScript
		set oldTIDs to text item delimiters
		set text item delimiters to sep
		set str to lst as string
		set text item delimiters to oldTIDs
	end tell
	return str
end join

on split(str, sep)
	tell AppleScript
		set oldTIDs to text item delimiters
		set text item delimiters to sep
		set lst to every text item of str
		set text item delimiters to oldTIDs
	end tell
	return lst
end split

We (referring mostly to myself) often post examples where handlers are performing too many tasks which gives a bad example. On the other hand AppleScript is an language for the hobbyist and not for aerospace programs. It therefore depends on how disciplined you want to write your code yourself.

Any handler that’s written (redundant) in more than 1 script should be in an library.

Debugging is mainly the biggest disadvantage, you’ll always need another script to call the handler. When you’ve created an hierarchical structure of dependencies simply copying the handler contents to a new empty script can’t be done that easily.

Don’t use it. It takes a lot of work to write the sdef files and limits your writing style because commands are not methods. Script libraries are OO, dictionary style is functional.

I’ve a free website astoolbox.wordpress.com for sharing my osax and share the link on this site and others. The actual osax you’ll download from my google drive.

But of course you do have to be sensible about where you draw the line between “tasks”. Sacrificing efficiency, legibility, and ease of debugging like this through overzealous adherence to someone else’s computing principle is not necessarily good scripting. :wink:

Of course, I was just showing how global leading companies have guidelines for their coders to write safe and most efficient code that’s more easy to debug and maintain. It’s a programming guideline, not a specific programming language guideline. It may also be important to know that this is one of the many things mentioned in such programming guidelines that together makes it all worthwhile.

One of the other things mentioned in those guidelines is the way you name the handlers. Which is just as important as how long the handler is. My example is bad though, handlers with self-explanatory names are easier to debug and errors concerning them are easier to understand. You’ll also keep namespace pollution to an minimum for programming languages who who only has an global namespace (AppleScript, Objective-C, C for example).

Thanks for the tips.
Yeah there’s in handler that I’ve created that is
Definitely redundant. It’s using a 2 lists of lists
it has a repeat with loop using the 1st list as the MAIn record selector
Then within that loop it has a repeat with each item in the 2nd list.
Both of the loops are executing the exact same code but just with
Different information. I could easily pull that code out
And have that as a seperate function that can be called for sure!
I’m sure I could probably figure out a way to possibly have
Only one repeat with loop if I can pass the right data thru!

Yeah i defenitly feel a mature programmer
And definitely see the debugging
But once I get it working smoothly I think I’ll know
When to create a library from it.

I am Definitely always tweaking my functions a
Bit to do more things!