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.0 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 1A6151F453 for ; Thu, 2 May 2019 09:11:58 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C2493120A71; Thu, 2 May 2019 18:11:52 +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 D8016120A19 for ; Thu, 2 May 2019 18:11:49 +0900 (JST) Received: by filter0076p3iad2.sendgrid.net with SMTP id filter0076p3iad2-16847-5CCAB456-9 2019-05-02 09:11:50.226497891 +0000 UTC m=+564191.861601559 Received: from herokuapp.com (unknown [54.234.139.236]) by ismtpd0025p1iad2.sendgrid.net (SG) with ESMTP id i1aFusRQQea7wphkjn0BaA for ; Thu, 02 May 2019 09:11:50.269 +0000 (UTC) Date: Thu, 02 May 2019 09:11:50 +0000 (UTC) From: shevegen@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 68007 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15817 X-Redmine-Issue-Author: shevegen 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: =?us-ascii?Q?6lbdtOg4RDRLuxD00eQtQKgoNAsge5d4xND7cbMQd0xNPGwAopPsMkxiRdpuQU?= =?us-ascii?Q?5u1TE6gDO5=2FBZvxqSGiV4EjTZE4tQ1C+TJR9ZfZ?= =?us-ascii?Q?gqKxjz+cEC3OUP4fBlcOcckLXU8rwOuq=2FAOor3i?= =?us-ascii?Q?cjQgqZORo1goA6cpwj=2FTgHKMQsTrsDZcaQC6pD9?= =?us-ascii?Q?zgcsRaWHTLoPaxWp4iWsR9ykvJpFJi9fAtg=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92524 Subject: [ruby-core:92524] [Ruby trunk Feature#15817] Warnings for undef_method and remove_method on initialize() 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 #15817 has been reported by shevegen (Robert A. Heiler). ---------------------------------------- Feature #15817: Warnings for undef_method and remove_method on initialize() https://bugs.ruby-lang.org/issues/15817 * Author: shevegen (Robert A. Heiler) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- Title: Warnings for undef_method and remove_method on initialize() Right now ruby warns you if you remove or undefine initialize, at the least if you run in verbose mode e. g. the -w flag. Example for such a warning: gtk_combo_box.rb:17: warning: undefining `initialize' may cause serious problems What am I trying to do here, that caused this warning to appear, actually? I am modifying some of the ruby-gtk code to extend the core gtk widgets with some "shortcuts", that is, functionality that I may use in order to write less code when I write ruby-gtk specific code. Part of this means that I have to modify how initialize works for some of these widgets; in particular enabling support for some Symbols via blocks given to the initializer (I happily use/abuse Symbols that way; ruby-gtk has also added a few Symbols in the last few years, in particular to avoid having to type long CONSTANT names when it is not necessary - see Kouhei Sutou's continued efforts here). In order to do this, and modify these gtk-widgets, I thus modify initialize - and ruby gives me warnings here. The first warning I actually got was: "warning: method redefined; discarding old initialize" Ok, fair enough. So my idea was ... "I'll simply remove the old initialize, and then set a new one, aka my own variant. That way I won't get the warning anymore." I then tried to use both remove_method, and undef_method, and while initialize is removed, ruby still warns me, e. g. with the "may cause serious problems" issue. This was the reason (and moment) for creating the issue request here. I should say that I always run all my ruby code with warning flags enabled, set in the shebang-header in a .rb file. I find it very useful that ruby tells me if there may be something wrong in general. However had, in this particular case, I actually consider ruby warning me to be a feature that I would prefer to not have, in that particular instance. The reason is that I am actually specifically telling ruby to get rid of the old initialize, so it is a bit surprising to me that ruby warns me. Here the assumption may be that the ruby user did not know what was done, and although I am still quite clueless, I actually think that in this case I knew what I wanted to do - that is, getting rid of the old initialize, then setting a new initialize. (Perhaps ruby could detect such a case, where the ruby users removes the old initialize, then specifically defines a new one; this may solve the issue here, but I have no idea how feasible this may be, or how much work. Just mentioning it really.) We can say that my approach is not a good one; this may well be, but the primary question is whether ruby should warn/notify us in such a case either way. I think you can find arguments for both cases, e. g. that ruby warns us (some people may want this, even in this case) when it comes to undef_method/remove_method on initialize only - but it may also equally be the case that the ruby user at hands knows what she/he/it is doing. And I believe that in the latter case ruby should NOT warn about this. Obviously ruby then would need a way to distinguish between these two cases: a) the case where the user wants to see a warning, because it may be helpful or for any other reason b) the case where the user does not want to see the warning, for whatever reason This makes the issue request here a bit complicated, because while I actually think that ruby should not warn in regards to undef_method/remove_method, there are also perfectly valid use cases for the latter, where ruby should warn. One use case can be when people dynamically add/remove methods and may "accidentally" - and automatically - remove initialize, so in this case it would be a GOOD thing that ruby warns them. But in other cases, such as in the use case described here, I would rather prefer to not have ruby print anything about this to me. There are workarounds of course - for example, I can temporarily silence on $VERBOSE, and then re-set it to the old value. I do this in other gems. There may be other workarounds - perhaps working on a new copy of initialize and then replacing the old one differently (not sure if these work ... perhaps with some variant of the *eval-family). All of which is fine - my primary reason here is that I believe it should be simple for the ruby user to tell ruby to not warn about a specific error at hand, e. g. in all the cases where the user knows the problem domain (and thus does not need the warning at hand). I have no really good general suggestion in how to improve this aspect here, because it may be better to make warnings in ruby more flexible in general. Perhaps even on a per module/class "namespace" - a bit similar to refinements, but with a simple(r) API and a simple(r) concept. I don't have a good proposal here either, so this is just a little bit of feedback really. (If there are more similar comments about warnings in ruby in general, please feel free to close the issue here and gather discussions in any other tracker issue if you feel this to be better.) To further explain the above issue - my use case was primarily motivated in order to silence the first warning. It took me a little bit by surprise that my course of action then led to another warning, which sort of defeated my original intent of silencing the other warning, since I now had a new warning issued on the commandline. :) Hopefully I could describe the intent/idea behind the suggestion. It is of course nothing that is hugely important, since it is just a warning and the code works fine, but I kind of like seeing no warnings on the commandline actually (don't know why but I dislike seeing warnings when I can avoid them). PS: I think for the particular issue at hand, I will do the old trick with temporarily modifying $VERBOSE. It feels a bit hackish, but it also kind of works, and I can then silence the specific warning at hand, e. g. "wrap" the offending code part between $VERBOSE or two method calls that modify $VERBOSE; so perhaps a more general solution may be to be able to modify $VERBOSE through method calls in general, though I don't know if this would make the code too slow, or where this method should reside (Kernel? Not sure) - I just think it may be nicer to read, API-wise, to have a method rather than have to modify $VERBOSE. But that is just an opinion really; the more important thing is that modifying $VERBOSE does work, so the functionality already exists for us to use as-is. -- https://bugs.ruby-lang.org/