Subj : Re: [Rhino] Continuations in Rhino
To   : Sam Cheung <sy_cheung@yahoo.com>
From : Igor Bukanov <igor@fastmail.fm>
Date : Sat Mar 06 2004 09:00 pm

Sam Cheung wrote:
> Could you please tell me the reason why this feature is in a fork
> instead with the offical build?

Probably mail from Christopher Oliver, (res1cf5x at verizon dot net), 
2003-01-23, explains that best:
----------------------------------------------------------------------

Thanks for that information, Igor.

Ovidiu, as of right now my thinking is that it is better to retain the 
forked version of Rhino used by Cocoon for the time being. In my 
opinion, in order to properly integrate another interpreter with the 
Rhino core, the Rhino core will require a major refactoring to eliminate 
the use of implementation inheritance The reason that it is virtually 
impossible to merge my changes now is due to the fact that 
implementation inheritance doesn't provide a stable contract for derived 
classes. Igor has changed virtually every base class my code depended on 
(as he should be allowed to) in incompatible ways. This will continue to 
happen as he fixes bugs, etc.

In addition, if you look through the list of fixes, none of them seem 
particularly significant, so there is little gain in value for Cocoon 
users by doing this merge.

Well, so there you go. I'm open to suggestions on what action to take next.

Regards,

Chris


Igor Bukanov wrote:

 > Christopher Oliver wrote:
 >
 >>  Hi Igor,
 >>
 >> I intended to attempt to merge the rhino snapshot I modified last 
year to support the Apache Cocoon project with the current Rhino cvs, 
but I now notice that you have made very extensive changes to the base 
interpreter and debugger. Can you offer any suggestions on how to merge 
my code with what you've done? There seem to be few comments explaining 
the nature of your changes or what problems they are intended to solve.
 >
 >
 >
 > Few reasons for changes:
 >
 > 1. Fixing
 > http://bugzilla.mozilla.org/show_bug.cgi?id=61579
 > http://bugzilla.mozilla.org/show_bug.cgi?id=83051
 > http://bugzilla.mozilla.org/show_bug.cgi?id=114583
 > http://bugzilla.mozilla.org/show_bug.cgi?id=154693
 > http://bugzilla.mozilla.org/show_bug.cgi?id=159334
 > http://bugzilla.mozilla.org/show_bug.cgi?id=173906
 > http://bugzilla.mozilla.org/show_bug.cgi?id=181834
 > http://bugzilla.mozilla.org/show_bug.cgi?id=184107
 >
 > Note although 173906 is related to the optimizer, the final fix 
touched the interpreter as well to ensure that the interpreter and 
compiler calls the same code for function initialization.
 >
 > 2. Making possible to debug functions that where defined prior a 
debugger load.
 >
 > 3. Extending limits on code size. Part of it is related to fixing 
159334, and the other items are related to number of elements in array 
literals [] and making sure that interpreter does not create different 
slots for the same strings.
 >
 > 4. Inlining of calls to interpreted functions to avoid creation of 
the argument array and wrapping of double values into Double objects.
 >
 > I believe it would be easy to make custom interpreters now as is 
would require to extend only Interpreter/InterpreterData as 
InterpretedFunction/InterpretedScripts methods currently just calls 
static methods in Interpreter with passing InterpreterData to them. It 
would be trivial to change them to call non-final methods in 
InterpreterData.
 >
 > Regards, Igor
 >

.