[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>

9 messages 2014/01/02

[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2014/01/02

[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>

10 messages 2014/01/03

[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>

48 messages 2014/01/03

[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>

33 messages 2014/01/03
[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — SASADA Koichi <ko1@...> 2014/01/06

Intersting challenge.

[#59541] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — Eric Wong <normalperson@...> 2014/01/04

Hi, I noticed a trivial typo in array.c, and it fails building struct.c

[#59583] [ruby-trunk - Bug #9367][Open] REXML::XmlDecl doesn't use user specified quotes — "bearmini (Takashi Oguma)" <bear.mini@...>

12 messages 2014/01/06

[#59642] [ruby-trunk - Bug #9384][Open] Segfault in ruby 2.1.0p0 — "cbliard (Christophe Bliard)" <christophe.bliard@...>

11 messages 2014/01/08

[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>

A while ago I created a proof-of-concept that I intended to use in my

16 messages 2014/01/15
[#59794] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/15

On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59808] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/16

Em 15-01-2014 19:42, Eric Hodel escreveu:

[#59810] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/16

On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59826] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/17

Em 16-01-2014 19:43, Eric Hodel escreveu:

[#59832] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/17

On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[ruby-core:59707] [ruby-trunk - Bug #9397] Lambda#=== raises `ArgumentError` if the lambda accepts 0 args or requires more than 1

From: Myron@...
Date: 2014-01-12 07:27:32 UTC
List: ruby-core #59707
Issue #9397 has been updated by Myron Marston.


> Why lambda?
> You can use proc for such purpose.

Users can use rspec's expectations with any kind of object.  We can't arbitrarily restrict it and say, "you can't use lambdas".  With some new features we're adding, we're leveraging ruby's `===` protocol, and we can't control what kind of objects users pass to us.

Why is it desirable for a built-in type to raise `ArgumentError` for `===` rather than returning false?

----------------------------------------
Bug #9397: Lambda#=== raises `ArgumentError` if the lambda accepts 0 args or requires more than 1
https://bugs.ruby-lang.org/issues/9397#change-44224

* Author: Myron Marston
* Status: Rejected
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* ruby -v: 1.9+
* Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
Ruby 1.9 introduced `===` on lambdas/procs so that you can put them in case statements.  I'm a fan of this, but there's an unfortunate side effect I've run into recently.

If you have a lambda that accepts 0 args (e.g. `lambda { }`) or requires more than 1 arg (e.g. `lambda { |x, y| }`), calling `===` on it will raise an `ArgumentError`.  I understand why: lambdas are strict about the number of arguments, and `===` is just an alias of `call` now.  However, this makes things difficult in a gem when you want to use `===` to match arbitrary objects (since it's the general-purpose protocol ruby provides for that purpose) and there may be lambdas provided by the user.  I ran into this in RSpec recently, and my (hacky) solution is to `rescue ArgumentError`:

https://github.com/rspec/rspec-support/commit/caf76c5de26ea1ca93f09f1097a0092ee4bf828d

It would be nice not to have to do this, and IMO, `===` on all built-in types should maintain the contract that they can be called with 1 arg and will not raise an error.  Consider that ruby's syntax doesn't even allow you to call `===` with 0 or more than 1 argument unless you resort to hacks like `send` (e.g. `obj.send(:===, x, y, z)`).  Given that, I think that `===` on lambdas should return false rather than raising an ArgumentError if the lambda does not support being called with 1 argument.





-- 
http://bugs.ruby-lang.org/

In This Thread

Prev Next