super and previous_def ignore block arguments

[HertzDevil]

The following:

class Foo
  def foo
    yield
  end
end

class Bar < Foo
  def foo
    super
    super { puts 2 }
    super { puts 3 }
  end
end

Bar.new.foo { puts 1 }

only prints 1, whereas the same code prints also 2 and 3 in Ruby. Passing the wrong arguments to Bar#foo shows that these two overloads are defined:

• Bar#foo()
• Foo#foo(&block)

On the other hand, Bar.new.foo produces an undefined method 'foo' for Object error on the super call without a block. Similar errors also happen for previous_def. The current workaround is to declare a block and forward it manually, but now any other method parameters must also be manually forwarded in super:

class Bar < Foo
  def foo(&block)
    super(&block)
# ...

Ideally we should detect that Bar#foo in fact accepts a block, but is this possible? Or should super require a block argument if and only if the enclosing def uses a block elsewhere? (Note that both cases imply the block must be captured.)

[asterite]

I don't think this is a bug? In the end there's one overload with a block and one without one.

In reality I think we might need to change the language so that if a method exists in a type then methods are looked up in just the type. If ko overload matches it's an error. Parent methods are only looked up if no method with that name exist in the child.

I'll later send examples with code. But with the current semantics this isn't a bug.

[beta-ziliani]

I do consider this an error, as the actual behavior isn't consistent.

What I would expect is to Bar#foo be considered as not taking a block (as now), but then error because there's no Foo#foo() to call with super. I think this goes in line with what you're saying.

[Sija]

Since the first call to super in Bar#foo only forwards the block, shouldn't the whole method be defined as Bar#foo(&) only?

[beta-ziliani]

Since the first call to super in Bar#foo only forwards the block

How do you know that? What if Bar defines a foo() method? To me, in such cases one needs to be explicit about the block.

[Sija]

I know that because the super call requires it. Also, I don't follow - Bar defines foo...

[straight-shoota]

@beta

but then error because there's no Foo#foo() to call with super

Isn't that exactly what's happening right now?

class Foo
  def foo
    yield
  end
end

class Bar < Foo
  def foo
    super # Error: undefined method 'foo' for Object
  end
end

Bar.new.foo

[robacarp]

I don't think I have a preference about the behavior but it would certainly help to improve the error message, though perhaps that's tracked somewhere else. Run this code on Crystal 1.6.2:

require "colorize"

class Foo
  def only_if_coordinator : Nil
    yield
  end
end

class Bar < Foo
  def only_if_coordinator : Nil
    if false
      yield
    else
      super
    end
  end
end

b = Bar.new

b.only_if_coordinator do
  pp "blah"
end

The error message is:

Error: undefined method 'only_if_coordinator' for Colorize::ObjectExtensions

Which doesn't provide any helpful guidance on why it can't find a method, or why it's looking at Colorize::ObjectExtensions. The source of that name is certainly some bubbling up behavior where it's looking for the appropriate super candidate, but it's pretty confusing.