>From my perspective, these changes would fit the criterion of "generally useful"
I took a look at the metaobject patch from Helma, and it seems like it seeks to accomplish something very similar to what I'm doing with crosscheck. So, for what it's worth, I would also like to see something resembling this as part of the core library. In order to simulate a browser host environment with custom javascript code (For several reasons, writing the host environment in javascript is much easier than doing so in java), I need to have generic get/set/ delete operations that do not necessarily know the name/index of the property in advance. Thus far, I've been using AspectJ to monkey patch ScriptableObject and intercept calls to get/set and friends to check for a __do_get__, __do_set__, __do_remove__ properties. I would also like a way to control enumerability from inside javascript. On Jul 23, 8:09 pm, Norris Boyd <[EMAIL PROTECTED]> wrote: > On Jul 22, 12:58 am, John Leach <[EMAIL PROTECTED]> wrote: > > > > > Dear list, > > > One of the problems I've had in my JavaScript development tools > > project Frizionehttp://code.google.com/p/frizione > > is that Helma is using a modified version of Rhino, as does > > YUICompressor. Unfortunately that means they don't play well together, > > so I had to launch YUICompressor as a process - which seemed > > ridiculous. > > > I've built a little sub project, which you can find > > here:http://code.google.com/p/frizione/source/browse/branches/BleedingEdge... > > This uses a clean Rhino codebase, with separate modified Java source > > files, then compiles to produce two jar files - the unmodified Rhino > > jar (the purpose is not to do this, just grab the prebuilt jar from > > mozilla) and a separate jar file which contains the modified Rhino > > code. > > > With that done, Just load the modified jar before the standard Rhino > > jar, and everything works nicely. > > > Having said that, I'd like your opinion on licensing. Some of the > > projects are MIT, some BSD, and of course Rhino is tri-license. I've > > included all the licenses, but I don;t know if that is enough. The > > second problem is that I have to (necessarily) include the Rhino > > sources, which I'm not wildly happy about. I suppose I could use Ant > > CVS to grab the code, which would be better. Any advice greatly > > appreciated. > > > FYI, is the build.xml for toolsrc broken? It uses "classes" (lines 79, > > 81, 87, and 91) and "js.jar" (lines 83 and 90) which I converted to "$ > > {classes}" and "${dist.dir}/${rhino.jar}" respectively. Works a treat > > with those changes made. > > > John Leach > > Verona, Italy > > > P.S. for James Burke - I haven't been able to integrate ShrinkSafe. I > > took a look at the code, but it seems to modify the Rhino Main class, > > instead of rolling its own. I don;t know enough about ShrinkSafe (nor > > how it is used) to do the modifications right now. Perhaps the Helma > > and YUICompressor modifications can help... > > > John > > Ideally we'd just incorporate the changes needed by Helma and > YUICompressor back into Rhino itself, provided they're generally > useful. Do you know what the nature of the changes to Rhino are? > > --Norris _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
