Why do you think of NilClass#to_proc?

Ruby
1

I have two minds about using a NilClass#to_proc

class NilClass
  def to_proc
    Proc.new{ |*a| a }
  end
end

Or

class NilClass
  def to_proc
    Proc.new{ nil }
  end
end

Which makes the most sense?

I thought of the first b/c often default procedures are simply pass-thru
procedures.

On the other hand, is neither a good idea? Is any definition of
NilClass#to_proc simply too “dangerous”?

2

Uh, yea s/why/what/.

3

Why would you do that? I can’t think of any situation where I would
need this, in whichever version.

– Matma R.

4

Hi,

Thomas S. wrote in post #1060469:

I have two minds about using a NilClass#to_proc

class NilClass
  def to_proc
    Proc.new{ |*a| a }
  end
end

Or

class NilClass
  def to_proc
    Proc.new{ nil }
  end
end

Which makes the most sense?

The second solution seems more intuitive to me, since it’s a kind of
“empty proc”: all parameters are discarded and the proc returns nil.

But like Bartosz already said: What’s the use case for this feature?

5

Andrew Grimm wrote in post #1060484:

I had a look at nil last year

[1, 2, 3].each(&nil)
doesn’t cause any errors, it just returns an enumerator.

[…]

I’d try to avoid monkeypatching NilClass if possible.

This isn’t a problem with nil.to_proc. You just have to know that nil is
treated specially in the “&” syntax for method calls (it’s equivalent to
calling the method without a block, the to_proc method is not called).
Which makes a lot of sense, by the way. Especially when passing around
blocks.

6

On Friday, May 11, 2012 4:42:52 PM UTC-4, Jan E. wrote:

The second solution seems more intuitive to me, since it’s a kind of
“empty proc”: all parameters are discarded and the proc returns nil.

That’s what I thought too, but then I never came across an actual use
for
that definition.

But like Bartosz already said: What’s the use case for this feature?

If you have a method that takes an optional block and no block is given
then it can default to the pass-thru proc via convenient:

def initialize(&block)
  @block = block.to_proc
end

But I suppose that’s the crux of the issue with this: which default proc
is
the right one for a given use case?

7

On Sat, May 12, 2012 at 6:42 AM, Jan E. [email protected] wrote:

The second solution seems more intuitive to me, since it’s a kind of
“empty proc”: all parameters are discarded and the proc returns nil.

But like Bartosz already said: What’s the use case for this feature?

I had a look at nil last year

[1, 2, 3].each(&nil)
doesn’t cause any errors, it just returns an enumerator.

Passing in &nil to a method causes block_given to return false:

def block_given_tester
if block_given?
puts “Block given”
else
puts “Block not given”
end
end

block_given_tester(&nil) # => Block not given

Even when I create NilClass#to_proc, it still says block_given? is
false, unless I explicitly call nil.to_proc:

class NilClass
def to_proc
Proc.new{ nil }
end
end
block_given_tester(&nil) # => Block not given
block_given_tester(&nil.to_proc) # => Block given

I’d try to avoid monkeypatching NilClass if possible.

Andrew

8

What intent is Proc.new { nil } conveying?

I am confused as to the purpose of this.

Will I get pink unicorns that way? Or does
this solve any real problem, other than
giving people a headache when they try to
understand this?

9

Am 12.05.2012 um 16:46 schrieb Intransition:

On Friday, May 11, 2012 4:42:52 PM UTC-4, Jan E. wrote:

The second solution seems more intuitive to me, since it’s a kind of
“empty proc”: all parameters are discarded and the proc returns nil.

That’s what I thought too, but then I never came across an actual use for that
definition.

You need it if you want to explicitly not pass a block to super. Even
super() will pass on a block. Only super(&nil) doesn’t.

But like Bartosz already said: What’s the use case for this feature?

If you have a method that takes an optional block and no block is given then it
can default to the pass-thru proc via convenient:

def initialize(&block)
  @block = block.to_proc
end

But I suppose that’s the crux of the issue with this: which default proc is the
right one for a given use case?

IMO, don’t mess with NilClass#to_proc. There’s no need and you break
things if you do. Therefore it’s a bad idea IMO.

regards
Stefan, aka apeiros