No problem :)
I was busy last few days with my daily work, in this case I will check
your patch and put comments.
In the meantime, I thought about integrating modules with
ScriptableObject. What I mean by that? Currently in patch we have a
nice way to load modules from JavaScript files.I think it will be nice
to have a way to define modules as set of implementations of
Scriptable interface.
I thought about following solution. We will have package level
annotation, called @Exports (to be aligned with Modules naming
convention). This annotation will point to classes which instances
will be exported by module. Let code speaks :)
in package-info.java file:
@Exports(MyFirstObject.class,MySecondObject.class)
package com.myproject.mypackage;
and in JavaScript:
var test = require("com/myproject/mypackage");
var obj = new test.MyFirstObject();
What do you think about it?
Jarek
W dniu 10 lutego 2010 12:43 użytkownik Attila Szegedi
<[email protected]> napisał:
> Actually, I was informed on the commonjs list that there's a new set of
> compliance tests at
> <http://github.com/kriskowal/commonjs/tree/master/tests/modules/1.0/> and the
> one on interoperablejs is obsolete.
>
> Also, just this morning i put out a new patch at
> <https://bugzilla.mozilla.org/show_bug.cgi?id=540724> that already has all
> the tests I wrote in it - this likely makes your work unnecessary; I'm sorry
> I didn't wait on you, but I have scarce spare time to work on this, so when I
> do have, I take advantage of it... By all means though, give it a review. I
> did end up taking your approach and including the files, as the new set of
> files wasn't available through command line SVN...
>
> Anyway, others might want to take the opportunity to check the current patch
> - it's now tested with 60% coverage; the untested stuff is mostly to do with
> cache revalidation. It passes all the compliance tests + my additional
> implementation tests.
>
> Also, a big improvement compared to the previous patch is that I made
> require() threadsafe, with good concurrent use properties, while not
> sacrificing performance for single threaded use. So it can now be used to
> load modules on demand into a shared top-level scope (which is something many
> server-side JS embeddings do).
>
> Attila.
>
> --
> home: http://www.szegedi.org
> twitter: http://twitter.com/szegedi
> weblog: http://constc.blogspot.com
>
> On 2010.02.10., at 12:31, Jarosław Pałka wrote:
>
>> Ok,
>>
>> I will include it in my patch,
>>
>> Jarek
>>
>> W dniu 8 lutego 2010 10:52 użytkownik Attila Szegedi
>> <[email protected]> napisał:
>>> I don't have a problem with depending on external SVN repo. It's unlikely
>>> that a googlecode SVN will go anywhere. The Rhino build already pulls
>>> libraries from Maven repositories. I actually started by adding:
>>>
>>> <target name="get-interoperablejs">
>>> <exec executable="svn" dir="build/test">
>>> <arg value="checkout"/>
>>> <arg value="http://interoperablejs.googlecode.com/svn/trunk/"/>
>>> <arg value="interoperablejs-read-only"/>
>>> </exec>
>>> </target>
>>>
>>> to testsrc/build.xml and making junit depend on it:
>>>
>>> <target name="junit"
>>> depends="junit-compile,coverage-instrument,get-interoperablejs">
>>> ...
>>>
>>> This makes it reside in build/test/interoperablejs-read-only.
>>> Alternatively, we could have it go under
>>> testsrc/org/mozilla/javascript/commonjs/module. But I'm really not a fan of
>>> hosting 3rd party code in Mozilla CVS, for legal reasons. Yes, I know
>>> InteroperableJS is MIT licensed, but still.
>>>
>>> Attila.
>>>
>>> On 2010.02.08., at 9:48, Jarosław Pałka wrote:
>>>
>>>> Before I prepare my patch we need to decide where to put
>>>> interoperablejs. I don't think that having dependencies to external
>>>> SVN repo is a good solution. I think the best way is to simply commit
>>>> content of http://interoperablejs.googlecode.com/svn/trunk into
>>>> mozilla/js/rhino/testsrc/interoperablejs. This way we can also do a
>>>> changes in tests itself.
>>>>
>>>> Let me know what do you think about it.
>>>>
>>>> Regards,
>>>> Jarek
>>>>
>>>> W dniu 8 lutego 2010 08:59 użytkownik Attila Szegedi
>>>> <[email protected]> napisał:
>>>>>
>>>>> Hi
>>>>>
>>>>> yes, please. I did start working on a JUnit driver for them myself, but
>>>>> if you already have it completed, I'll be happy to accept your patch and
>>>>> save me some work.
>>>>>
>>>>> Thanks,
>>>>> Attila.
>>>>>
>>>>> On 2010.02.08., at 8:57, Jarosław Pałka wrote:
>>>>>
>>>>>> Attila,
>>>>>>
>>>>>> I have finished tests with interoperablejs. I wonder how should I share
>>>>>> it with you. Should I attach tests suite to bugzilla issue?
>>>>>>
>>>>>> Jarek
>>>>>>
>>>>>> W dniu 8 lutego 2010 08:14 użytkownik Attila Szegedi
>>>>>> <[email protected]> napisał:
>>>>>> 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
>>>>>>> <[email protected]> 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 <[email protected]>
>>>>>>>>>
>>>>>>>>>> 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 <[email protected]> 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.
>>>
>>
>>
>>
>> --
>> Bloguje się tutaj http://primitive.jogger.pl
>> A czatuje tutaj [email protected]
>
>
--
Bloguje się tutaj http://primitive.jogger.pl
A czatuje tutaj [email protected]
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
