Norris Boyd wrote:
> On Jan 16, 1:16 pm, Marc Guillemot <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> what should be considered as Rhino public API and therefore not (as far
>> as possible) modified?
>>
>> An example: I'd like to improve the error message "Cannot find function
>> xx" to something like "Cannot find function xxx on yyy". This message is
>> generated by ScriptRuntime#notFunctionError which is... public.
>>
>> Or are considered as public API only the classes available in the
>> generated JavaDoc?
>>
>> Cheers,
>> Marc.
>> --
>> Blog:http://mguillem.wordpress.com
> 
> In general I consider the API to be the classes in the public javadoc.
> It's an error I made 10 years ago not separating the API into a
> different package.
> 
> Methods in ScriptRuntime are public because they are referenced from
> compiled scripts. We can't change the signature of those methods since
> people don't necessarily recompile all their scripts on every
> release.
> 
> That being said, we can change the error messages that are created.
> What's the yyy in your proposed message? Want to propose a patch?

yyy would be for instance the string representation on which the method
was called.

Adding this can only be done in changing the signature of
ScriptRuntime#notFunctionError to accept an additional parameter but you
seem to say that it shouldn't be done to allow script compiled with
earlier versions of Rhino should continue to work. Is this position
definitive? I'm quite skeptic concerning such things that a project
wants to maintain but that are not covered by tests. Are you really sure
that the changes made between previous releases respect that?

Yes, I want to propose a patch but I first need to know what kind of
changes are allowed.

Cheers,
Marc.
-- 
Blog: http://mguillem.wordpress.com
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino

Reply via email to