--4e896351_19a52566_4992
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 Hello ruby-core,  

First, thank you to everyone involved in RubyConf! I had a number of good discussions there, and coming from these I would like to humbly propose a potential solution to some of the issues surrounding Modules. What I would propose would be to treat Modules (and subsequently Classes) as "library forms", and to introduce methods Module#only, Module#except, Module#prefix, and Module#rename. These names are not arbitrary, and in fact correlate directly with the methods described for library formsn Scheme's R6RS standard (section 7.1, http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.1). Module#prefix and Module#rename are straight-forward, as their names imply.

Module#only takes a list of symbols and returns a Module containing only the matching methods. Module#except takes either another Module or a list of identifiers and would return a Module refined according to the argument. So, for example:

 module A
 def foo; end
 def bar; end
 end
 module B
 include A.only(:foo)
 def baz; end
 end
 #=> module B now contains methods :foo and :baz, but not :bar

These could also be used in combination with shadowing bindings to accomplish much of what refinements intended. For example:

 module A; end
 module B; end
 class String
 include A
 include B
 end

 # later class Foo
 String = String.except(A)
 #=> from this point on, any resolution of "String" in this scopeould
 # use the "shadow" String class which contains methods from
 # module B but not any from module A.
 end

I think this should also remove the performance concerns from refinements, as nothing has changed regarding scoping rules or constant look-up. Instead, there would be two "String" classes now: Foo::String and ::String. Thoughts?

- Josh  


--4e896351_19a52566_4992
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div>
                    Hello ruby-core,
                </div><div><br></div><div>First, thank you to everyone involved in RubyConf! I had a number of good discussions there, and coming from these I would like to humbly propose a potential solution to some of the issues surrounding Modules. What I would propose would be to treat Modules (and subsequently Classes) as "library forms", and to introduce methods Module#only, Module#except, Module#prefix, and Module#rename. These names are not arbitrary, and in fact correlate directly with the methods described for library forms in Scheme's R6RS standard (section 7.1,&nbsp;http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.1). Module#prefix and Module#rename are straight-forward, as their names imply.</div><div><br></div><div>Module#only takes a list of symbols and returns a Module containing only the matching methods. Module#except&nbsp;takes either another Module or aist of identifiers and would return a Module refined according to the argument. So, for example:</div><div><br></div><div>&nbsp; &nbsp; module A</div><div>&nbsp; &nbsp; &nbsp; def foo; end</div><div>&nbsp; &nbsp; &nbsp; def bar; end</div><div>&nbsp; &nbsp; end</div><div>&nbsp; &nbsp; module B</div><div>&nbsp; &nbsp; &nbsp; include A.only(:foo)</div><div>&nbsp; &nbsp; &nbsp; def baz; end</div><div>&nbsp; &nbsp; end</div><div>&nbsp; &nbsp; #=&gt; module B now contains methods :foo and :baz, but not :bar</div><div><br></div><div>These could also be used in combination with shadowing bindings to accomplish much of what refinements intended. For example:</div><div><br></div><div>&nbsp; &nbsp; module A; end</div><div>&nbsp; &nbsp; module B; end</div><div>&nbsp; &nbsp; class String</div><div>&nbsp; &nbsp; &nbsp; include A</div><div>&nbsp; &nbsp; &nbsp; include B</div><div>&nbsp; &nbsp; end</div><div>&nbsp; &nbsp;&nbsp;</div><div>&nbsp; &nbsp; # later/div><div>&nbsp; &nbsp; class Foo</div><div>&nbsp; &nbsp; &nbsp; String = String.except(A)</div><div>&nbsp; &nbsp;nbsp; #=&gt; from this point on, any resolution of "String" in this scope would</div><div>&nbsp; &nbsp; &nbsp; # use the "shadow" String class which contains methods from</div><div>&nbsp; &nbsp; &nbsp; #odule B but not any from module A.</div><div>&nbsp; &nbsp; end</div><div><br></div><div>I think this should also remove the performance concernsrom refinements, as nothing has changed regarding scoping rules or constant look-up. Instead, there would be two "String" classes now: Foo::String and ::String. Thoughts?</div><div><br></div><div>- Josh</div>
                <div></div>
            
--4e896351_19a52566_4992--