简体   繁体   English

如何检查JRuby脚本是否定义了特定方法?

[英]How can I check whether a JRuby script defines a particular method?

I'm embedding Ruby within a Java app via JRuby, and need to test whether a given Ruby script defines various methods. 我正在通过JRuby将Ruby嵌入Java应用程序中,并且需要测试给定的Ruby脚本是否定义了各种方法。 I have a very simple JRuby setup: 我有一个非常简单的JRuby设置:

ScriptingContainer container = new ScriptingContainer();
Object receiver = container.runScriptlet(new FileReader(SCRIPT_PATH));

where SCRIPT_PATH is a File with these contents: 其中SCRIPT_PATH是具有以下内容的文件:

def processDoc(doc)
  return doc
end

I now want to determine whether the script defined the processDoc method, but can't find a way other than actually invoking processDoc , which I'd prefer to avoid. 现在,我想确定脚本是否定义了processDoc方法,但是除了实际调用processDoc ,找不到其他方法,我希望避免。 I've tried respond_to? 'processDoc' 我尝试了respond_to? 'processDoc' respond_to? 'processDoc' and methods.include? 'processDoc' respond_to? 'processDoc'methods.include? 'processDoc' methods.include? 'processDoc' , neither of which works, as the following successful set of assertions indicates: methods.include? 'processDoc'methods.include? 'processDoc' ,如以下成功的断言集所示:

Object doc = new Object();
assert container.runScriptlet("respond_to? :processDoc") == Boolean.FALSE;
assert container.runScriptlet("methods().include? 'processDoc'") == Boolean.FALSE;
assert receiver == null;
assert container.callMethod(receiver, "processDoc", doc) == doc;

Are there any other techniques I can use to determine if a simple JRuby script defines a method with a particular name, without actually invoking the method? 我是否可以使用其他任何方法来确定简单的JRuby脚本是否定义了具有特定名称的方法,而无需实际调用该方法?

When defining a global method, it becomes a private method of Object . 定义全局方法时,它将成为Object的私有方法。 You must therefore use the include_all parameter for respond_to? 因此,您必须将include_all参数用于respond_to? to get this to work: 使它起作用:

container.runScriptlet("Object::respond_to?(:processDoc, true)")

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM