Issue #11934 has been reported by Yusuke Endoh.

----------------------------------------
Feature #11934: A feature to drop dynamics dynamically
https://bugs.ruby-lang.org/issues/11934

* Author: Yusuke Endoh
* Status: Feedback
* Priority: Normal
* Assignee: 
----------------------------------------
Ruby is a dynamic language.  Everything is possible in runtime.

So, how about a feature to prohibit some dynamic features in runtime?

~~~~
Foo = 1

RubyVM.drop_dynamics

Bar = 2        #=> cannot define new constant
Foo = 2        #=> cannot redefine a constant
def foo; end   #=> cannot define a method
class Baz; end #=> cannot create a new class
~~~~

Ruby's dynamic property greatly restricts performance.  However, it is a bad idea to limit Ruby's dynamics.  It is Ruby's identity, and is actually useful in some aspects such as debugging, daily-scripting, research, hobby-use, etc.

That being said, when a program is in production, we don't necessarily use the dynamic features at any time during execution.  Typically, they are used only in initialization of application, such as eval-for-DRY and monkey patching.  After the initialization is done, we can drop (some of) dynamic features in some situations.

Currently, when considering optimization of Ruby implementation, we (the core-team) must always care the possibility of redefinition of any built-in methods.  That is not sound.  This proposal gives us a "normal" condition for considering optimization.  We can easily apply a lot of optimizations, like constant folding and method inline expansion.  In addition, some advanced analyses like JIT/AOT compilation, type inference and whole program optimization will be applicable much more effectively.

--

It is arguable what features are prohibited.  IMO, it is relatively easy to drop the following features.

* (re)definition of constants
* (re)definition of methods (including singleton methods an aliases)
* (re)definition of classes/modules
* inclusion of modules

Aggressively, we may limit the following features.

* destructive modification of some kind of objects (such as making string literal frozen by default)
* some meta-programming features like `Object#send`
* `eval` and `instance_eval`
* addition of instance variables
* XXX <- feel free to add your unfavorite features

We should care about a trade-off between compatibility impact and optimization effect.

--

I'm half-joking, but half-serious.  I'm unsure if this is really a great idea, but surely better than just restricting Ruby specification by default (such as frozen string literal).  This may be a key feature towards Ruby3x3.  

What do you think?

-- 
Yusuke Endoh <mame / ruby-lang.org>



-- 
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>