Re: Libraries and effiency
Re: Libraries and effiency
- Subject: Re: Libraries and effiency
- From: Tetsuro KURITA <email@hidden>
- Date: Mon, 16 Aug 2010 09:56:41 +0900
On 2010/08/12, at 4:08, Tommy Bollman wrote:
>
> On 9 Aug 2010, at 07:44, Tetsuro KURITA wrote:
>
>> Thanks for comments on ModuleLoader.
>>
>>> Last night I looked at Tetsuros code, and his way of make this mechanism work, taking for granted that the code does what it is supposed to do. It is all very clever, but IMHO, this approach is dangerous.
>>> The things I find dangerous is that you can't hardcode paths to libraries, and that the module loader will search several libraries and use the script library found in the latest path. It is stuff like this that creates situations where it is very hard to detect what is really going on when something is at err.
>>
>> The way of finding libraries of ModuleLoader is similar to other script
>> language i.e. Perl, Ruby and so on. Also AppleMods have same way. This is
>> widely adapted.
>>
>> Off cause, Using hardcode paths is simple but cause a tough problem that
>> you must manage library locations by hand.
>>
>> History and other systems show that it's a good way to avoid hardcode paths
>> to libraries.
>
> The system is very good for developers, no doubt about that. But for users… not so good, when their base - framework is out of sync, as a matter of fact I think we should aim higher, than the scripting frameworks of perl and ruby, just lets face it, the average AppleScript user, isn't that into it at all, we need something simpler and easier to resolve shall we make people into using others libraries.
I could not understand the difference between developers and users you mean.
It is very difficult even closing the level of module system of perl and ruby.
I hope you will show your idea by your product.
>>> Predefined paths and all that, is really modern,, and gives AppleScript a load mechanism like all other languages. But the names of the libraries loaded should always be unique if they are to be loaded by such an implicit method. It should as a matter of fact be disallowed to use the same name for a library residing in two different directories.
>>
>> ModuleLoader allows duplicated libraries's name, because libraries can be specified by a sub paths from predefined paths.
>>
>> For example;
>>
>> property ModuleA1 : module "subfolder1:ModuleA"
>> property ModuleA2 : module "subfolder2:ModuleA"
>>
>
> I didn't think you could do that.
Can't I do that ?
Above statements works with ModuleLoader.
http://homepage.mac.com/tkurita/scriptfactory/software/OSAX/ModuleLoader/manual/en/04_moden_way/contents.html
> My system is not quite finished yet, but it works for hardcoded library paths as we speak, but without resolving dependencies of any kind, it can be found in parts and will be integrated into a whole.
>
> < http://www.macscripter.net/viewtopic.php?id=33712 > Server and script for listing handlers.
> < http://www.macscripter.net/viewtopic.php?id=33487 > Script and sound server ! to insert loadstatments, open scripts from predefined paths , show them in finder.
>
> < http://www.macscripter.net/viewtopic.php?id=33763 > show differences between to applescript files.
>
> < http://www.macscripter.net/viewtopic.php?id=33821 > scripts which opens hardcoded paths in editor.
>
> < http://www.macscripter.net/viewtopic.php?id=33808 > script server skeleton
>
I hope you will collect your system into your package.
It is not easy to try your system.
For example, I had to need to change the code to try "ScriptLibraryLoader".
Don't assume that the name of startup disk is "Macintosh HD".
Obtain the reference to user's home directory by using "path to" command.
> I would like to add is that the ideal solution as I see it, is that you and Hamish collaborated on creating one common loader system,
> which uses his versioning number system. but your loader mechanism.
I agree with that module loading system should have ability to load a module specified with a version number.
I will try it.
> Any overriding of anything, for developer purposes should be done
> in a project specific property.list file, any user specific changes to the system should be done as specified by Philip. Aker.
If a convenient library is implemented, it will be used.
> Your osax's loader command should override the load script command, to make it tackle both hardcoded paths and direct implicit paths to module directories.
The mechanism of the loader can't not completed by a single OSAX command.
In the case of ModuleLoader, osax commands and a script object are collaborating.
Even if I can override the load script command, it will be nonsense.
=======================================================
Tetsuro KURITA
E-mail: email@hidden
http://homepage.mac.com/tkurita/scriptfactory/en/
=======================================================
_______________________________________________
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