ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: shevegen@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:84005] [Ruby trunk Feature#14145] Proposal: Better Method#inspect
Date: Thu, 30 Nov 2017 12:23:01 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-68086.20171130122300.1210bb73eb356807@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-14145.20171130104208@ruby-lang.org

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) # => #<Method Klass#foo>
# after:
some_interesting_object.method(:foo) # => #<Method Klass#foo(first_arg, *other_args, keyword_arg:)>
```

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}"} = <default>"
      when :keyreq then "#{name || "kw#{i+1}"}:"
      when :key then "#{name || "kwparam#{i+1}"}: <default>"
      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)
# => #<Method Array#at(param1)>

# Ruby method, proper param names
CGI.method(:escape)
# => #<Method CGI.escape(string)>
Addressable::URI.method(:parse)
# => #<Method Addressable::URI.parse(uri)>
Addressable::URI.method(:join)
 => #<Method Addressable::URI.join(*uris)>

# We can't extract default values, but at least we can say they are there
Addressable::URI.method(:heuristic_parse)
# => #<Method Addressable::URI.heuristic_parse(uri, hints = <default>)>
```

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/

  parent reply	other threads:[~2017-11-30 12:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-14145.20171130104208@ruby-lang.org>
2017-11-30 10:42 ` [ruby-core:84004] [Ruby trunk Feature#14145] Proposal: Better Method#inspect zverok.offline
2017-11-30 12:23 ` shevegen [this message]
2017-11-30 14:39 ` [ruby-core:84007] " hanmac
2017-11-30 15:41 ` [ruby-core:84009] " zverok.offline
2017-12-04  7:54 ` [ruby-core:84076] " ko1
2017-12-04  8:15 ` [ruby-core:84077] " hanmac
2017-12-04 11:35 ` [ruby-core:84085] " zverok.offline
2018-10-27 23:56 ` [ruby-core:89585] " guilhermekbsa
2018-10-28  6:47 ` [ruby-core:89596] " eregontp
2018-10-28  9:10 ` [ruby-core:89599] " Ruby-Lang
2018-11-06 23:36 ` [ruby-core:89738] " keystonelemur
2018-11-07  7:06 ` [ruby-core:89743] " nobu
2018-11-07  8:35 ` [ruby-core:89746] " keystonelemur
2019-01-10  5:02 ` [ruby-core:90967] " matz
2019-01-11  1:49 ` [ruby-core:91009] " ko1
2019-03-11  6:30 ` [ruby-core:91754] " ko1
2019-03-11 15:20 ` [ruby-core:91786] " zverok.offline
2019-03-13 20:21 ` [ruby-core:91819] " eregontp
2019-03-14  6:45 ` [ruby-core:91827] " duerst
2019-06-13  5:44 ` [ruby-core:93086] " nobu
2019-07-14  7:01 ` [ruby-core:93747] [Ruby master " ko1
2019-07-14 13:39 ` [ruby-core:93760] " zn
2019-07-14 17:58 ` [ruby-core:93762] " eregontp
2019-07-30  7:07 ` [ruby-core:94025] " ko1
2019-10-04 17:57 ` [ruby-core:95229] " richard.schneeman+ruby-lang
2019-10-27 10:45 ` [ruby-core:95570] " zverok.offline
2019-11-19  9:05 ` [ruby-core:95886] " ko1
2019-11-19 18:42 ` [ruby-core:95887] " zverok.offline
2019-11-20  0:41 ` [ruby-core:95888] " zverok.offline
2019-11-20  4:43 ` [ruby-core:95891] " ko1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-68086.20171130122300.1210bb73eb356807@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).