Project

General

Profile

Feature #15961

Always warn for URI.{,un}{escape,encode}

Added by jeremyevans0 (Jeremy Evans) 25 days ago. Updated 24 days ago.

Status:
Open
Priority:
Normal
Target version:
-
[ruby-core:93372]

Description

These methods have both had a verbose mode warning for almost 10 years. If we ever plan on removing them, we should switch from a verbose mode warning to a regular warning. If we don't, people will still use them, and run into their problems (see #12235, #9806).


Files

uri-escape-always-warn.patch (1.18 KB) uri-escape-always-warn.patch jeremyevans0 (Jeremy Evans), 06/26/2019 08:27 PM

History

Updated by zverok (Victor Shepelev) 25 days ago

I am not sure, but can this warning be more helpful? Like method's documentation, which says:

This method is obsolete and should not be used. Instead, use CGI.escape, URI.encode_www_form or URI.encode_www_form_component depending on your specific use case.

Or is there a reason/standard/convention for warnings to be brief, even if less useful?..

Updated by shevegen (Robert A. Heiler) 24 days ago

I am not sure if such a verbose message would make sense, even more so as
long as the ruby user has no trivial way to silence a particular warning
(without e. g. the $VERBOSE trick to assign to a new value, make a change,
then re-assign to the old one).

In general, while you can argue that a more verbose warning can be more
helpful, in ruby it is often the case that warnings are sort of short.
I can not say whether this is deliberate or may be inspired by japanese
devs playing with english and having fun (see zombie threads) :) - but
I believe that, for consistency, it may be better to be short/succinct
if possible. In the long run perhaps ruby may provide more fine-tuned
control over warnings but I think matz has to think about this, perhaps
past ruby 3.0. There is actually quite a lot of ruby that focuses on
the "human side of errors/problems", if you think about it - the did-you-
mean gem too. Rubocop too, if you think about it from an "enforce a
spec for consistency" point of view (e. g. autocorrect option, if it
works, in a ruby project).

I have no particular opinion about the change itself but I think jeremy
has a valid point with reallife problems encountered in this regard (e. g.
the old bug reports).

Also available in: Atom PDF