• 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: AS Library Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AS Library Question


  • Subject: Re: AS Library Question
  • From: has <email@hidden>
  • Date: Sat, 19 Dec 2015 14:12:52 +0000

On 17/12/2015 15:12, Chris Page wrote:
On Dec 14, 2015, at 4:26 PM, has <email@hidden> wrote:

You'll need to eliminate any mutable state such as preferences they might have by e.g. converting those properties and their related handlers into OO code...
Do you mean that your loader writes modified libraries back to disk? AppleScript specifically does not. This makes it safe for library state to change, because it only affects what's in memory--just like Mach-O frameworks, and libraries in other languages.
??? No of course not.

If you haven't taken the time to study AppleMods' Loader yourself, here's a summary of how it operates:

AM Loader is safe because each user script creates and owns its own unique Loader instance. That Loader instance then recursively loads all of the libraries used by the user script. It caches as it goes, of course, so that if user script A loads libraries B and C, and library B also loads C, then the same instance of C is shared by both.

When another user script wants to load libraries, it too creates and owns its own unique Loader instance, which maintains its own cache as it loads. There's no sharing of state between Loader instances, so it's impossible for the two user scripts' dependency graphs to intersect.

What do you mean by “convert properties and handlers into [Object-Oriented] code”? Properties and handlers are hallmarks of object-oriented programming. Did you mean “create handlers for reading and writing state instead of letting clients directly manipulate properties” and “add code to save/restore state in preferences”?

No. I mean avoiding mutable state within the library script by packaging that state into its own script object + constructor which the user's script can instantiate and retain/share itself. For example, consider an existing number formatting library that has a 'decimalSeparator' property which the user sets to indicate whether periods or commas are used as decimal separators (e.g. "3.14" vs "3,14"), and a 'formatNumber' handler that the user calls to format a number as string.

The only way to ensure this existing logic works reliably is to wrap it in a script object which the client script instantiates before use:

on makeNumberFormatter()
    script NumberFormatter

        property decimalSeparator : "." -- may be "." or ","

        on formatNumber(n)
            ...
        end

    end
end


The user's script can then call makeNumberFormatter() once to obtain their *own* formatter object, storing it in a property for subsequent reuse if they wish.


Alternatively, you could eliminate state entirely by passing the separator string as an argument to every formatNumber call:

on formatNumber(n, decimalSeparator)

end

although for things like localization settings that are typically only set once that gets a bit tedious, which is why we have 'preferences' in the first place. We just have to remember that *our preferences* are personal to us, and not to be imposed upon everyone else in the world by force.

...and you'll have to get rid of any sub-modules (which the AS loader doesn't support) and copy-and-paste all of their code into the top-level module.
Please elaborate. Libraries can use other libraries, and library bundles can contain libraries.


It's a couple years since I tried AS's library loader, but as I recall I was unable to put a library (L) within a library bundle (B) such that B could use 'script "L"' to access it while libraries outside of L could not. If B cannot import L, that is a limitation that makes complex libraries a PITA to construct. If other libraries can see L without explicitly stating "B/L", then that is a serious defect creating huge risk of name collisions between unrelated libraries.

I'm off shortly so don't have time to spelunk it again, but if you haven't figured out the problem by January then ask me then. (Inadequate documentation certainly didn't help, so at minimum that *definitely* needs sorted.)


has
_______________________________________________
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


References: 
 >Re: AS Library Question (From: has <email@hidden>)
 >Re: AS Library Question (From: has <email@hidden>)
 >Re: AS Library Question (From: Chris Page <email@hidden>)

  • Prev by Date: Re: AS Library Question
  • Next by Date: Re: AS Library Question
  • Previous by thread: Re: AS Library Question
  • Next by thread: Re: AS Library Question
  • Index(es):
    • Date
    • Thread