On 2010-08-31, at 21:52:31, Tetsuro KURITA wrote:
Do you mean osaxen receiving AppleEvent descriptors like 'object' and 'object specifier'?
Consider loading two modules (ModuleA and MoudleB) which depending on same module (ModuleC).
The ModuleC of ModuleA will not share the instance with the ModuleC of ModuleA.
Also consider following statements.
set ModuleA to import "ModuleA"
set ModuleB to import "ModuleA"
I expect ModuleA is ModuleB. But loading modules by a simple osax command cause ModuleA is not ModuleB.
There is a reason why both of ModuleLoader and AppleMods load modules through a script object. This mechanism causes complex syntax to load modules.
Yes, and I think, like Takaaki and Ed, that this is one of the reasons that library loaders are not often used. So we have to fix it.
Do you have any ideas for syntax to load modules and to describe its dependencies ?
I think dependency problems are well studied and have very advanced solutions available these days. The basic ones have a formal name something like 'priority queue' or 'binary tree priority queue'. There is an old book giving an introduction called "Foundations of Computer Science/C Edition" by Aho and Ullman: <
http://infolab.stanford.edu/~ullman/focs.html>. Maybe in chapter 5.
But It may be impossible to develop simpler syntax than one of ModueLoader without AppleScript language supports.
I can provide language support if needed. But first I will try some osax tricks because they could be easier.
Are you a developer of Apple ?
I hope following ability of AppleScript.
* A handler can know a script object which call the handler.
* A script object returned from OSAX
* OSAX command can access the script object calling the command.
In my understanding, above functions can not implemented by current OSAX system.
I'm still evolving the lower levels of the ModuleManager framework and mostly thinking about the best file format to describe libraries for scriptors.
These are tough questions you ask, and I won't be thinking about osax problems for at least a few weeks. If something required does not work in an osax, we'll move up to a component. I can tell you that in the past, Apple used to inject a secret identifier property in some of their scripts. Sneaky guys those AppleScript Chris fellows.
Basically I think #1 and #3 requests are not possible without an injected property (at the very least) and a recompile of the script. That would be impossible for run only scripts and I believe we'd have to consider very carefully any side effects caused by recompiling -- like what if there is a tell block to an application that is not available? Then, because of the scenario of dependencies, whatever chain was in effect would be smashed due to recompilation failure. This is not the same situation as Apple and their secret identifier because I think they put it in at compilation time (in AppleScript Studio) and always have control. I think that is a distinguishing difference between library loaders and script editors.
At first glance #2 seems possible but I've never tried it.
Maybe I could ask about _how_ to solve the problem? I see you are going by a way that is natural in some languages but not in AppleScript. Obviously, because you are getting into the fundamental script object and the characteristics of OSA. But, I was asking in my previous question:
"What description of libraries provides the most bang for the buck?"
IOW, what information must a library description of a script contain so that you don't get the problems you are asking about? For instance, when a script is registered into a library:
• It can keep a list of a script's handlers and properties.
• It knows the name and location of the script.
• It has assigned the script a unique ID.
In addition:
• Information about a script in a library description don't have to be permanent -- it can exist only for a certain period of time and then be deleted.
• If our import function loads the script then it can add extra information to the library description. An import function can know if it's already loaded a script from a certain location because it can keep a history list of what it has loaded. Therefore, if A is imported and A imports C, then, when B imports C, I believe it is the user's choice as to whether or not they want separate instances of C. In either case, we can deal with their choice.
Philip Aker
echo email@hidden@nl | tr a-z@. p-za-o.@
Democracy: Two wolves and a sheep voting on lunch.