From: shevegen@... Date: 2019-03-28T07:54:00+00:00 Subject: [ruby-core:92032] [Ruby trunk Bug#15732] Strict mode Issue #15732 has been updated by shevegen (Robert A. Heiler). This suggestion confuses me quite a bit. I am not sure of the use case; or perhaps I don't quite understand it. I think what you essentially suggest is to be able to run/interprete any given .rb file with additional restrictions in place, yes? So a bit like the old $SAFE settings, if I understood it correctly. On the other hand ... hmm. Not creating $1 when a regex is used - why would that have to be done? The $1 etc... are already different to other normal $ variables - they are very volatile. I can not think of any situation where they may be a problem? Disallowing re-assigning constants ... I think this is largely any personal preference, so I can understand that part a little. Some people may prefer that constants could not be changed in ruby, so I am not at all against the possibility. Note that I am not among those who have a problem with it. I think most people who come from the point of view that changing constants is bad, approach the issue from the wrong point of view, similar with the older File.exists? versus File.exist situation. One partial application of ruby's philosophy is to let you do what you want to, when you want to (at the least in many situations). So the issue, in my opinion, is not that a "constant" can be changed - I guess the issue is that people have in their mind the notion that a "constant is a constant and does never change"; so when you don't focus on the word constant that much, perhaps these people may suddenly no longer have the same strong opinion. Could give another name to it. :) But as said, I also understand the other argument, even though I have no problem with constant; the only comment I remember having made in the past is that it wuold be nice if we could have more control over warnings issued by ruby in the future (but it may also not be a huge priority; just may be nice if we could have more "fine tuned control" eventually). Passing a block to a method that doesn't "accept blocks" ... raising an exception .... hmmmmmmm. Every method accepts a block without one having to do something. That's part of what makes ruby great. If you don't need it, then don't make use of the pased block? I usually use something like "if block_given?" ... and then next line ... "yielded = yield", or something funny like that; easier for me to continue to work with a variable. :P I am not sure why anyone may want to prevent it from happening in ruby. Using reversed keywords as argument names ... actually, I once had a use case for this, e. g. when I was autogenerating HTML and CSS. I wanted to add a parameter called "class", for a CSS class, but this was not possible. My solution was to simply give it a slightly longer name, aka "css_class" and that was fine (I also added "css_style", so I could differ between a CSS class, and a CSS style attached to a given HTML tag). So from this point of view, I can partially understand the use case - buuuuuuuut I am also not sure if this is so important or good to have. I also don't think inspiration should be drawn from JavaScript because the "design" of JavaScript makes me quite angry in general. I often compare JavaScript to PHP and I honestly often can not tell the difference as to which one is worse. I am not at all in principle against some of the suggestions given here per se, mind you; and I think a general "strict mode" in ruby would be somehwat similar what we may have had in the past with $SAFE - but at the same time, the suggestion also confuses me. It seems to bundle together different things into a larger "meta" suggestion, and while I also understand that this is sometimes possible, I don't quite fully understand the suggestion. In my opinion it would be better to split the suggestions up, if necessary, and then make separate descriptions of use cases. As it is right now, I think it makes it very very hard to want to go about favourably, mostly because different ideas are bundled together, with different quality or (perceived) need. Some of the suggestions can also confuse people, such as recursive definition of names, e. g. the example of class A; end; class B; class A; def me; A; end; end - and, quite honestly, this is an example where it would be better if people would keep code SIMPLE and not confusing, so I am not sure if anyone should WANT to need to add features that could be confusing. Ruby is not JavaScript; neither is the design similar. But I think the format of the suggestion here is problematic - bundling together too many ideas makes it hard(er) to want to reason in favour of any of them really, even if I understand a few of them to a certain extent. ---------------------------------------- Bug #15732: Strict mode https://bugs.ruby-lang.org/issues/15732#change-77356 * Author: localhostdotdev (localhost .dev) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- A lot of issues could be easily prevented with a strict mode, for instance: - Passing a block to a method that doesn't accept blocks could raise an exception, e.g. methods would be required to explicitly ask for a block (def a(..., &block)) - $1, $2, etc. variables when matching with a regex would not be created - Could throw error when re-assigning constant And maybe more controversial: - Using reversed keywords as argument names - Using method name as argument name - Using ambitious class/constant/method names (e.g. `class A; end; class B; class A; def me; A; end; end` I'm sure there is more, using things rubocop does for instance: https://github.com/rubocop-hq/rubocop/blob/master/manual/cops.md I could be implemented as a magic header, e.g. `# strict_mode: true`. This is obviously a similar idea from Javascript's strict mode: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode -- https://bugs.ruby-lang.org/ Unsubscribe: