• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: libraries vs copy/paste
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libraries vs copy/paste


  • Subject: Re: libraries vs copy/paste
  • From: has <email@hidden>
  • Date: Sat, 20 Dec 2008 15:33:54 +0000

Chris Page wrote:

One sort of "scaling" is that you should be able to write libraries in
AppleScript without resorting to writing a scripting addition or a scriptable
application. You tend to be stuck putting all the code you need into a single,
monolithic file and using copy/paste to "share" code.

You *already can* write libraries (modules) in AppleScript; the problem is that the language lacks a decent module manager for importing those modules into scripts. I tried to push this from the community side a few years back by developing the Loader system for AppleMods, but that never took off for a number of reasons - the largest of which, IMO is the huge lack of interest in formal, organised code reuse that pervades the AppleScript community today, and has done since its inception. (Yes, there are some more advanced AppleScripters who use modules in their own projects, but none of this knowledge or work is shared with the community at large in any meaningful way.)


For AppleScript modules to become more than a hand-rolled, "for advanced users only" thing, Apple will really have to provide the lead: adding an easy-to-use module loader to the language itself; providing a range of free, well-designed modules for users to use; and educating the bulk of AppleScripters as to the benefits of formal code reuse, without which the current copy/paste culture is not going to change.

It's a tricky problem in a lot of respects, but if Chris P (or anyone else for that matter) wants to discuss the requirements and challenges involved, I'll be happy to contribute what knowledge and experience I have.

...

tom wible wrote:

i've able to reuse code via load script/parenting (cascading, actually, 2
levels) each extending the previous...


That's really an abuse of AppleScript's inheritance/delegation mechanism, and won't scale well or be easy to understand or maintain.

If you want to do C-style includes, you'd be better writing your own 'script compiler' that takes a bunch of AppleScripts, combines their source code into one, and compiles it via Script Editor or osascript. That should give you a reasonable chance of discovering name conflicts between modules at compile-time, as the compiler will complain if you have more than one property or handler declaration with the same name. If you wanted to be really clever, you could even have it scan each script for comments that look like #include "some_name.applescript" and locate their dependencies automatically based on those comments.

[BTW, IIRC, Script Debugger also provides its own includes-based library feature, where scripts are merged at compile-time. I've never used that feature though, so can't comment on it with any expertise, and it's proprietary which makes it a non-starter for driving any sort of mass adoption.]


The other approach is to do Python-style imports, where each module remains an independent namespace. That avoids any chance of unrelated modules tramping on each others' toes, so unlike C-style includes is a safe, fully scalable solution. It can also support run-time as well as compile-time loading of modules, making it more flexible than an include-based system. It does mean a bit more typing when using module functions as you have to reference the module each time, e.g. my_module's some_handler(), but - as mentioned often enough - nothing in life comes for free.


If anyone wants a 'preview' copy of Loader 2.0, which promises to be a fairly decent third-party module loader if/when I find the time to finish it [1], drop us a note and I'll sling one over.

HTH

has

[1] This will depend on other work I'm currently involved in, which may force me to deliver a production release in spring. Anyone interested in seeing this happen is encouraged to send a note of interest off-list.
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


_______________________________________________
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
  • Prev by Date: Re: What's so great about AppleScript, anyway? (was Re: Tell Blocks Considered Harmful…)
  • Next by Date: Re: on scalability (was Re: on neophytes vs perfectionists)
  • Previous by thread: ‘run script’ best practices (was Application Script Menus)
  • Next by thread: Re: on scalability (was Re: on neophytes vs perfectionists)
  • Index(es):
    • Date
    • Thread