From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_PASS,T_DKIM_INVALID, T_RP_MATCHES_RCVD shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id CCC2320C11 for ; Thu, 30 Nov 2017 12:23:08 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 2CD95120A9A; Thu, 30 Nov 2017 21:23:06 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 56EAE120A99 for ; Thu, 30 Nov 2017 21:23:04 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=xLCGPqNku/DXb3d26n/EmgO6xI4=; b=ww7hd2y4XAtDboUua4 tqZKzV6YOsw3X7ubY418K8k9g7y5RZQ9KlhRQBYV1j080wyRIdFsganDy57kUNax XRJu6rtRsPby1LEP1t/47W8D7l/lXP6YnPE1OTnpaE6a/gC9gayKAp6fCUH9+7HV ShfldVJOj0iFxfeaM7tuGVWt0= Received: by filter0026p3mdw1.sendgrid.net with SMTP id filter0026p3mdw1-22717-5A1FF824-2F 2017-11-30 12:23:00.913001391 +0000 UTC Received: from herokuapp.com (ec2-54-196-95-145.compute-1.amazonaws.com [54.196.95.145]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id h6dl_XWFQ1y0I-em0prawQ for ; Thu, 30 Nov 2017 12:23:00.829 +0000 (UTC) Date: Thu, 30 Nov 2017 12:23:01 +0000 (UTC) From: shevegen@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 59142 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14145 X-Redmine-Issue-Author: zverok X-Redmine-Sender: shevegen 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS6yEcwZOx/AFRh7nVm9fu84oZ+JjH0PZG65oN OXXlxIoqk/XDPcBU/vetCFOoTNuYGdnbiffsdIGVOQvny9Iimab6fTu4Q5NwKOJFkIR9HFtV2/3PwT xObZpvTUAUX/8hobwIfz3My5vvUV1ipqI4MyznSn/J13t9sF68kIJZCqsg== X-ML-Name: ruby-core X-Mail-Count: 84005 Subject: [ruby-core:84005] [Ruby trunk Feature#14145] Proposal: Better Method#inspect 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 #14145 has been updated by shevegen (Robert A. Heiler). I have nothing at all against better diagnostics, introspection etc... However had, in that particular case that you showed above, I would personally not want it, even though I normally am always in favour of introspection. But to each their own - I have no problem if others can use it. I should also note that my contra this is only mild, so I ultimately would not have any real big objection to it either. My proposal would be to allow this to be customized or customizable, so that ruby hackers can decide on their own what they prefer. One could use symbols to toggle the behaviour such as via: :simple :expanded Where the latter may refer to the display that you described. But I guess in most ways, it really depends on the personal preferences of the ruby hacker. A good example how to solve this is one of my favourite gems of all times, the did-you-mean gem. The toggle situation is to ... either use the gem - or to uninstall it. :) That way people can decide which variant they prefer. Anyway, I don't want to make your suggestion too complex, since it really is simple - you propose a different default display purpose, which is an ok suggestion to make. In general it would be nice if ruby could allow for more customization and fine tuning of its internal behaviour or parts; see also Martin's proposal to have unicode-related stuff be easier debuggable; see also other suggestions to make threads more easily debuggable (by default) and so on and so forth. So I guess we can say that many people would like to have more control, better messages, different messages etc... - I guess the ruby core team has some things to ponder about towards the path of ruby 3.x with all of that. :) PS: Perhaps for testing purposes, the above could be enabled via a configure switch for post ruby 2.5.x, so that people could test it, and give early feedback, and then also provide more feedback here. The reason I mention this is because ruby 2.5.x changed a few things in regards to exceptions and messages, such as underlining the error, changing the stack trace display, etc... compared to ruby 2.4.x and I think people may need some days or a few weeks to adjust to it. Even adjusting to the did-you-mean gem took me a while. :) ---------------------------------------- Feature #14145: Proposal: Better Method#inspect https://bugs.ruby-lang.org/issues/14145#change-68086 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- The idea: When investigating (in example scripts, debugger or console) the library you are unfamiliar with, Ruby's reflection is very useful mechanism to understand "what it can": classes, modules, their constants, methods and so on. I propose to expose a bit more information Ruby has internally in `Method#inspect`: ```ruby # before: some_interesting_object.method(:foo) # => # # after: some_interesting_object.method(:foo) # => # ``` Dead-naive implementation: ```ruby class Method def signature recv = case receiver when Module "#{receiver.name}." else "#{receiver.class}#" end parameters.map.with_index { |(type, name), i| case type when :req then "#{name || "param#{i+1}"}" when :opt then "#{name || "param#{i+1}"} = " when :keyreq then "#{name || "kw#{i+1}"}:" when :key then "#{name || "kwparam#{i+1}"}: " when :rest then "*#{name || "rest"}" when :keyrest then "**#{name || "kwrest"}" end }.join(', ').prepend("#{recv}#{name}(") << ")" end def inspect "#<#{self.class.name} #{signature}>" end end ``` This works "sub-optimal" for methods implemented in C, yet pretty decently for Ruby-implemented methods: ```ruby # C method, default param names [1,2,3].method(:at) # => # # Ruby method, proper param names CGI.method(:escape) # => # Addressable::URI.method(:parse) # => # Addressable::URI.method(:join) => # # We can't extract default values, but at least we can say they are there Addressable::URI.method(:heuristic_parse) # => #)> ``` If the proposal is accepted, I am ready to implement it properly in C (for all callable objects: `Method`, `UnboundMethod`, `Proc`) -- https://bugs.ruby-lang.org/