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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>