Project

General

Profile

Actions

Bug #20505

closed

Reassigning the block argument in method body keeps old block when calling super with implicit arguments

Added by Earlopain (A S) 5 months ago. Updated 4 months ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:117992]

Description

You can call super without arguments and parenthesis to pass along all the enclosing method arguments to the parent method.

You can modify positional and keyword arguments before the call to super, and the parent method will recieve these modified values. With the block arg however that isn't the case:

class A
  def positional_arg(a)
    puts a
  end

  def block_arg(&block)
    yield
  end
end

class B < A
  def positional_arg(a = nil)
    a = 'b'
    super
  end

  def block_arg(&block)
    block = proc { puts 'b' }
    super
  end
end

B.new.positional_arg('a')
B.new.positional_arg
B.new.block_arg { puts 'a' }
B.new.block_arg

I would expect this snippet to print b four times. The actual output is b b a and LocalJumpError. To get the desired output I must pass the block along explicitly with super(&block).

I hope my example explains the issue good enough. I have looked through issues here and searched for documentation and haven't found any mention of this behaviour. Sorry if I missed something somewhere.

Updated by nobu (Nobuyoshi Nakada) 5 months ago

I think that's what it is.
Proc is an instantiated block representation, but not a block itself.

Updated by Earlopain (A S) 5 months ago

nobu (Nobuyoshi Nakada) wrote in #note-1:

I think that's what it is.
Proc is an instantiated block representation, but not a block itself.

Ok, I see what you mean. This makes sense, somewhat. You could also just assign a string literal which makes even less sense, didn't think about that beforehand

You do have two values hiding behind the same name which is pretty confusing. I would expect super to take the modified argument and raise when it is not blocklike, or perhaps raise earlier on assign when not blocklike.

Updated by mame (Yusuke Endoh) 5 months ago

Actually, super is totally confusing. Do you know that super() passes the block argument? I have been using Ruby for 20 years and never knew about it until recently.

class A
  def foo
    yield
  end
end

class B < A
  def foo
    super() # delegates the given block!
  end
end

B.new.foo { puts "Hello" } #=> Hello

As for super, I don't think it is a good idea to change the behavior based on only partial consistency.

My personal preference is to deprecate no-argument super, if possible. We have super(...) now, which looks much better to me.

Updated by Earlopain (A S) 5 months ago

mame (Yusuke Endoh) wrote in #note-3:

Actually, super is totally confusing. Do you know that super() passes the block argument? I have been using Ruby for 20 years and never knew about it until recently.

class A
  def foo
    yield
  end
end

class B < A
  def foo
    super() # delegates the given block!
  end
end

B.new.foo { puts "Hello" } #=> Hello

As for super, I don't think it is a good idea to change the behavior based on only partial consistency.

My personal preference is to deprecate no-argument super, if possible. We have super(...) now, which looks much better to me.

I believe super always passes the block along, unless you explitly do &nil. I guess it works out most of the time but it is one of the things I wish Ruby didn't do. But changing that would be hugely disruptive I think.

This goes along with all methods accepting a block without declaring they do so, and in that context always passing it along does make sense since the method may not even have a block arg to exicitly pass along.

Updated by matz (Yukihiro Matsumoto) 4 months ago

Keep the assignment to the block argument as it is; If we want to discuss super's behavior, let's discuss it in another issue.

Matz.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0