From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 74EAE1F405 for ; Mon, 17 Dec 2018 21:56:48 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id AE319120C56; Tue, 18 Dec 2018 06:56:44 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id DA0EE120C75 for ; Tue, 18 Dec 2018 06:56:39 +0900 (JST) Received: by filter0157p3mdw1.sendgrid.net with SMTP id filter0157p3mdw1-3205-5C181B94-16 2018-12-17 21:56:36.289624086 +0000 UTC m=+1607.751758172 Received: from herokuapp.com (ec2-54-204-143-200.compute-1.amazonaws.com [54.204.143.200]) by ismtpd0023p1iad2.sendgrid.net (SG) with ESMTP id qKCMMepVRfiI8eZ2kgPcoA for ; Mon, 17 Dec 2018 21:56:36.115 +0000 (UTC) Date: Mon, 17 Dec 2018 21:56:38 +0000 (UTC) From: zverok.offline@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65997 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15428 X-Redmine-Issue-Author: zverok X-Redmine-Sender: zverok X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4eNfHVhOxLzOlSF2JTF6uG92FGsrhzUqOBkB g+1Xt3UHe3Ehl78pTQWWA0PeoxZv/xO8RKi6Dp9GAE4KQPva1t2BLMNr8a/rB8daTfEuEbtAZATRbs hTVoZcAGdFMdM7jXl8NHjQQtLADtxMd9HwGlL0t2zc9FObgw8P2vqxoQeQ== X-ML-Name: ruby-core X-Mail-Count: 90591 Subject: [ruby-core:90591] [Ruby trunk Misc#15428] Proc composition: what can quack like Proc? X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15428 has been reported by zverok (Victor Shepelev). ---------------------------------------- Misc #15428: Proc composition: what can quack like Proc? https://bugs.ruby-lang.org/issues/15428 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- I believe, that solution of #6284 introduced important language inconsistency: as far as I can tell, it insists that **anything that responds to `#call`** is composable, e.g. **quacks like `Proc`**. The problem is, previously it was **never** this way. `#call` method has a nice shortcut of `.()`, but when you wanted to tell something can quack like proc, it **always** was done by defining `#to_proc` method. I understand it could be too late to ask, but I wonder why this inconsistency was introduced and is there a plan to take this step further? For me personally, this `#call`/`#to_proc` dichotomy was always weird and feels like it needs some unification (maybe anything having `#call` will automatically have `#to_proc` method?), but the situation when exactly one language feature treats it differently looks pretty weird for me. -- https://bugs.ruby-lang.org/