On 2010-09-01, at 10:25:48, Tetsuro KURITA wrote:
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.
I can't agree with you.
The solution ignoring dependency problems is not useful for me.
Well yes, but solutions for dependency problems have been studied a lot because of things like race conditions in threads, multiple processors, and all kinds of test engineering where data is coming in asynchronously.
Maybe I could ask about _how_ to solve the problem?
I am interested with simplifying syntax of ModuleLoader.
See following typical code of ModuleLoader.
property ModuleA : module
property ModuleB : module
boot (module loader) for me
I think "boot (module loader) for me" is agree.
If a handler can know the script object which call the handler, "for me" can be removed. If OSAX command can access the script object calling the command, "boot (module loader) for me" can be replaced with a simple command.
I have already given up solving above problems.
Like I said, Apple injected a secret identifier property in some of their scripts. So any handler can have access to the ID. I think they used it to distinguish between such things as the location of global variables in a project with multiple scripts. Because these kinds of scripts were used in AppleScript Studio projects, it would then be easy to coordinate the ID with the actual location of the script on disk or with a loaded script object.
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.
Who does list a script's handlers and properties ?
What is the purpose of the list of a script's handlers and properties ?
For finding out information about what a module or library or script contains.
Handlers and properties are associated with individual scripts.
Therefore it's possible to know which scripts contain which handlers.
I think what you are asking about handlers and script objects is something like this:
###
property id : "5052401A-7B71-4537-AD3E-627E852ECD81"
script bob
property properties : {beer:"Heineken", fish:"sockeye", id:"B9AA11D6-2541-4C6F-9FC5-3345BA289EFC"}
on run
properties
end run
on doit()
properties
end doit
end script
--run script bob
bob's doit()
But now you want in the doit() handler to: 'tell script of me to …'
And that's returning an error.
I show a handler that knows the 'id' of it's script. So if a library contains a mapping of handlers/properties to scripts, then I think it's possible for a handler to know its owner by asking the librarian. And consequently, if the librarian is the one who supplies the 'import' command which loads the script into the current context, then it can find the script object (because it has a unique id) and do things on behalf of the handler.
###
I hope I understand the details of the problem as you describe.
• It has assigned the script a unique ID.
What is the role of the unique ID. Why can a script be identified with its name ?
In OSA, a script doesn't really have a name because it's not required to have an associated file. It can have a property 'name' that is different than the name of its file on disk. It can be loaded by another script and loose it's identity because it's loaded into the context of it's new owner. Therefore, it's unreliable to use a name (or a path) to uniquely identify scripts. OSA uses OSAIDs to identify scripts and these are maintained by the generic component who translates them from a master id to a local id in the AppleScript component. But both of these kinds of ids are transient and are lost when the component is closed. So, component ids cannot be used as a permanent identifier.
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.
How do you keep single instance of C ? Known solutions are using AppleMods or ModuleLoader. Your 'import' command (simple osax command) can't help to keep single instance of C. I have already tried and gave up. I hope you can find the solution.
In the application and osax projects in ModuleManager.framework, I show that a library is assigned a unique id when it is created. It will be the same for scripts and other kinds of files registered with ModuleManager. It's 'import' command will know if it's already loaded a script with a particular unique id, and can make the choice whether or not to create a new instance.
echo email@hidden@nl | tr a-z@. p-za-o.@
Democracy: Two wolves and a sheep voting on lunch.