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:95692] [Ruby master Feature#16289] Reduce duplicated warnings for the change of Ruby 3 keyword arguments
Date: Tue, 05 Nov 2019 09:35:39 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-82480.20191105093539.0658ad3a130667ce@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16289.20191101032931@ruby-lang.org

Issue #16289 has been updated by shevegen (Robert A. Heiler).


Makes sense to me what mame wrote, so +1; marcandre's suggestion for a deprecation-specific
notice makes sense as well and may be useful past ruby 3.0 (if ruby 4.x may have more
incompatibilites than ruby 3.0; then there could be more distinct "Deprecated" or
"Deprecation" messages).

Daniel wrote:

> I think the issue is more that in a long-lived process you'll get only a few warnings
> in a large log, and it may be easy to miss unless you specifically grep for the warnings.

While your comment is perfectly reasonable and makes sense as well, I think this taps into
the older discussion about customizing warnings issued by ruby, so that people can adjust
ruby to different use cases (a bit like you can customize rubocop). But this may be a
discussion past ruby 3.0 perhaps. IMO what mame wrote makes sense too since it may not be
too overly useful to have your full screen overflow with the same warning-message spam
that you already know is a problem. (Of course if there was some way to customize it in
a simple manner, ruby users could then adjust this to their general use case - but I
don't want to dilute mame's suggestion here. Picking the "right" default behaviour
covering the most likely or "best" use case of course makes a lot of sense to me and
I think most ruby users who run into this situation are more likely to want to read cozy
and helpful messages on the commandline, and using logs only secondary. :) )

marcandr's suggestion has the advantage that the leading word "deprecated" can be
colourized quite easily, e. g. people could "style" it to red on their computer;
KDE Konsole supports R,G,B style too, I use that a lot myself for different colours
(HTML colours such as "tomato" or "orangered", but I am going off-topic here a
little bit; it is also not available to everyone, of course). But in general I think
mame's description makes a lot of sense.

Note that while I understand jeremy's comment about annoying messages "helping" 
people change their code, not everyone thinks that spam is that helpful. See also
past discussions about reversing the output of the errors so that some people 
have it easier to find the problem instantly, on the last part of the message,
whereas other ruby users prefer the old style. In the long run I think it would
be best to have some larger proposal for people being able to customize ruby
warnings (and perhaps error output to, to some extent), but it should be simple
to use too. But again, sorry for diluting here, +1 to what mame wrote. I don't
think "nagging" should be of higher priority than the goal of making it simpler
to read and understand what is going on - that is also in the spirit of the 
did-you-mean gem, if you ask me.

----------------------------------------
Feature #16289: Reduce duplicated warnings for the change of Ruby 3 keyword arguments
https://bugs.ruby-lang.org/issues/16289#change-82480

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
## Problem

Currently, the interpreter emits 200 lines of warnings against the following program.

```ruby
def foo(**opt); end
100.times { foo({kw:1}) }
```

```
$ ./miniruby -e 'def foo(**opt); end; 100.times { foo({kw:1}) }'
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
...
```

In theory, the warnings are not harmful because they don't stop or interfere the execution.  But in practice, I'm afraid if they are annoying because they flush all console logs away.
I think that the warning is not needed if the call is already warned.


## Proposal

How about limiting the count of warnings to at most once for each pair of caller and callee?

I've created [a pull request](https://github.com/ruby/ruby/pull/2458).  It records all pairs of caller position and callee iseq when emitting a warning, and suppress the warning if the same pair of caller and callee is already warned.

What do you think?



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

  parent reply	other threads:[~2019-11-05  9:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-16289.20191101032931@ruby-lang.org>
2019-11-01  3:29 ` [ruby-core:95627] [Ruby master Feature#16289] Reduce duplicated warnings for the change of Ruby 3 keyword arguments mame
2019-11-01  4:43   ` [ruby-core:95630] " Eric Wong
2019-11-01  4:38 ` [ruby-core:95629] " ruby-core
2019-11-01  7:03 ` [ruby-core:95631] " nobu
2019-11-01 13:26 ` [ruby-core:95634] " mame
2019-11-02  8:00 ` [ruby-core:95651] " mame
2019-11-02 12:56 ` [ruby-core:95653] " eregontp
2019-11-02 15:47 ` [ruby-core:95655] " ruby-core
2019-11-04 16:41 ` [ruby-core:95670] " daniel
2019-11-05  9:35 ` shevegen [this message]
2019-11-10 11:24 ` [ruby-core:95775] " eregontp
2019-11-10 22:20 ` [ruby-core:95780] " sam.saffron
2019-11-11  1:00 ` [ruby-core:95783] " sam.saffron
2019-11-29  8:12 ` [ruby-core:96025] " mame
2019-12-23  7:37 ` [ruby-core:96418] " ruby-core
2019-12-23 11:49 ` [ruby-core:96425] " mame
2019-12-23 12:51 ` [ruby-core:96427] " eregontp
2019-12-23 17:47 ` [ruby-core:96439] " merch-redmine
2019-12-23 21:49 ` [ruby-core:96441] " ruby-core
2019-12-24  7:06 ` [ruby-core:96452] " mame
2019-12-24  7:10 ` [ruby-core:96453] " matz
2019-12-24  7:23 ` [ruby-core:96455] " mame
2019-12-24  7:34 ` [ruby-core:96456] " mame

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-82480.20191105093539.0658ad3a130667ce@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).