On 2010.02.07., at 20:33, Jarosław Pałka wrote: > Attila, > > I was playing with your patch for few days, and one thing I found is annoying > NullPointerException when module is not found :), I believe we should have > more meaningful exception message. > > I am also working on tests, using http://code.google.com/p/interoperablejs/. > Were you trying to run your patch against these tests?
Hi, No, I haven't, but I definitely will now. I'm writing JUnit tests. I just recently discovered that there's an EMMA plugin for Eclipse, it greatly improves my progress towards good coverage. I have found few bugs myself. Also, I have found a way to make Require thread-safe for use with shared top level scopes. And by "found a way" I mean "found a more efficient way than using a coarse synchronized block on it" :-) Attila. -- home: http://www.szegedi.org twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com > > So far code looks good, > Regards, > Jarek > > W dniu 31 stycznia 2010 20:15 użytkownik Attila Szegedi <szege...@gmail.com> > napisał: > 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. > > Attila. > > On 2010.01.19., at 23:45, Attila Szegedi wrote: > > > Hi, > > > > I created a Bugzilla issue to track this work: > > <https://bugzilla.mozilla.org/show_bug.cgi?id=540724> > > I already attached a patch with the implementation to the above issue, so > > feel free to check it out and provide feedback. I believe that the JavaDocs > > I provided are sufficiently comprehensive so that no one should have > > trouble understanding how's it used. > > > > Be warned it's quite untested - I'll proceed with writing some tests > > tomorrow. > > > > Attila. > > > > -- > > home: http://www.szegedi.org > > twitter: http://twitter.com/szegedi > > weblog: http://constc.blogspot.com > > > > On 2010.01.18., at 14:54, Jarosław Pałka wrote: > > > >> Count me in as well. > >> > >> Jarek > >> > >> 2010/1/18 Rapha <rspe...@gmail.com> > >> > >>> I like the idea. Are you thinking of the 1.1 spec ( > >>> http://wiki.commonjs.org/wiki/Modules/1.1 ) ? > >>> > >>> Raphael > >>> > >>> On Jan 17, 1:35 pm, Attila Szegedi <szege...@gmail.com> wrote: > >>>> Folks, > >>>> > >>>> I'm contemplating adding CommonJS Modules implementation to Rhino > >>> codebase proper. I'd create org.mozilla.javascript.commonjs package to > >>> hold > >>> it, and we could have a method similar to initStandardObjects(), i.e. > >>> initCommonJs() that'd initialize it - basically install a require() > >>> function > >>> with the expected semantics in the top-level scope. I want leave some of > >>> its > >>> aspects - most notably lookup of the module script - pluggable, defined > >>> by > >>> interfaces in the org.mozilla.javascript.commonjs package, so that > >>> specific > >>> embeddings of Rhino (JS app servers) can install their own module resolver > >>> logic. I'd provide a default implementation for the shell too. > >>>> > >>>> As I foresee that several Rhino-based JS products will adopt CommonJS in > >>> the near future, it seems desirable to not have all of them reinvent the > >>> wheel (even though some already did, I'm guilty of coding my own require() > >>> too in the next-gen version of my company's server-side JS enviroment...). > >>>> > >>>> Opinions? > >>>> > >>>> Attila. _______________________________________________ dev-tech-js-engine-rhino mailing list dev-tech-js-engine-rhino@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
