On 2010.02.10., at 22:28, Martin Blom wrote: > On 31/01/2010 20:15, Attila Szegedi wrote: >> Hi all, >> >> I just put out the second implementation patch >> at<https://bugzilla.mozilla.org/show_bug.cgi?id=540724>, against current CVS >> HEAD. Check it out if you're interested. I have worked on this for I most of >> my free time I can have for coding in the last 12 days, and have arrived at >> a much better design than what was in the first attempt. I attached a >> comment to the Bugzilla issue describing the design decisions I took. It all >> feels round to me at the moment. I took care to document all classes and >> interfaces in great detail. I'll proceed with writing tests for it, but if >> you don't mind reviewing and trying bleeding-edge stuff, go for it. >> > > Hi Attila and list, > > I've started playing with the patch in the context of my ESXX project and > while I haven't had time to finish yet I have a couple of questions: > > 1) I already have a path array in ESXX, which also happens to be a JS array > that is searched from the front. However, having two path objects is weired, > so I'm wondering if we could either perhaps replace the 'secure' argument > with a 'paths' argument (Scriptable) so I can inject mine, or add a method > that returns Require's paths object so I can use that one instead?
You can easily obtain the paths of a require instance. Remember, a require() function is just a JS object, so you can do: Require require = ...; NativeArray paths = ScriptableObject.getTypedProperty(require, "paths", NativeArray.class); > 2) I have a special property named 'esxx.location' that contains the URI of > the currently executing file. For this to work I need to know when the Script > is executed. It could be solved by making Require.executeModuleScript > protected, or better, adding an exec method to ModuleScript. I see - you need a post-exec hook. Okay, that's a reasonable thing. I actually at one point in time had ModuleScript.exec(), but I scrapped it. The reason is in the way SoftCachingModuleScriptProvider is implemented; if you look into it, ModuleScript instances in it are not even preserved, but they are deconstructed/reconstructed into/from the ScriptReference as needed. This is done so that there's no strong reference Script objects being held, so unused scripts can indeed get unloaded. (functions have pointers to their parent scripts, so as long as there's any function from the script reachable in any of the currently running JS program instance, they won't get GCed, otherwise they can be). For the same reason, you shouldn't create such post-exec hook by creating a wrapper around Script that itself implements Script with pre/post processing - you'd screw up soft caching as you can't sneak in a strong reference to your wrapper Script object into the Script object that Rhino c ompiles for you, which'd be required to ensure soft cache doesn't load multiple reachable copies of scripts (& functions). So, an explicit way to register a post-exec hook is the cleanest solution - I'll look into where would this fit best. Thank you very much for taking time to look into this and make suggestions. Attila. -- twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com home: http://www.szegedi.org > Comments? > > -- > ---- Martin Blom --------------------------- [email protected] ---- > Eccl 1:18 http://martin.blom.org/ > > _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
