Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Class generated for interface-implementing block does not match signature when arg not specified #69

nedgar opened this issue Mar 27, 2011 · 5 comments


Copy link

@nedgar nedgar commented Mar 27, 2011

interface Console do
  def write(s:String):void;end

class Greeter
  def greet(m:String, c:Console)
    c.write m
end"Hi") {
  puts "Yo"

Generates the following class for the block:

  public static class __xform_tmp_2 extends java.lang.Object implements Console {
    public void write() {

At runtime, this results in:

Exception in thread "main" java.lang.reflect.InvocationTargetException
Caused by: java.lang.AbstractMethodError: BlockTest1$__xform_tmp_2.write(Ljava/lang/String;)V
    at Greeter.greet(BlockTest1.mirah:8)
    at BlockTest1.main(BlockTest1.mirah:12)

I've also had it crash the VM on one of the SWT Snippets, if this happens when it's in a callback e.g. due to button press.

The signature should be write(String m) instead, even if m is not used.

Copy link

@baroquebobcat baroquebobcat commented Aug 26, 2011

Would you expect it to give you an error about the wrong # of arguments on the block or to try to work anyway?

Copy link

@consiliens consiliens commented Aug 26, 2011

"Comment 1 by rogerpack2005, May 30, 2011
I was able to reproduce this :)"

Copy link

@nedgar nedgar commented Sep 6, 2011

I think at the time I expected it to generate a write(String s) method where s is ignored in its body, but maybe it does make more sense for the compiler to flag the mismatch in the # of args.

Copy link

@baroquebobcat baroquebobcat commented Jan 8, 2012

I've got an idea for fixing this that I'll look into next week. Essentially, when turning the block into a closure class, check the provided args against the args of the fn it's implementing and raise an error if they don't match.

We could probably handle the no args passed to the block case there too.

right now it just blindly uses the arguments for the block when constructing the method definition.

Copy link

@baroquebobcat baroquebobcat commented Feb 26, 2012

now, Mirah complains when the block's args don't match. 98acfef

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.