From: Joshua Ballanco <jballanc@...>
Date: 2011-10-25T14:17:21+09:00
Subject: [ruby-core:40331] Re: 2.0 feature questionnaire

--4ea64658_2a79ec49_1124
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Monday, October 24, 2011 at 10:29 PM, Charles Oliver Nutter wrote:
> 2011/10/1 SASADA Koichi <ko1@atdot.net (mailto:ko1@atdot.net)>:
> > - Remove Proc binding
> 
> I added this one. Anyone who has ever attempted to optimize Ruby knows
> this is one of the biggest roadblocks. If any time, any local state
> can be seen by code you've passed a block to, you can't optimize any
> of that code in a way that would make it inaccessible.
> 
> I'd also argue it breaks encapsulation in the same awful way that "retry" did:
> 
> def foo
>  password = get_password
>  transaction do
>  service.auth(password)
>  service.do_something
>  end
> end
> 
> ...
> 
> def transaction(&block) # my evil patch
>  steal_password eval('password', block)
> end
> 
> Any library that can patch "transaction" can see the "password" local.
> Shouldn't local variable encapsulation be sacred?
> 
> Get rid of it.

I've had an alternate idea to accomplish something like a compromise, but I'm still a ways away from having anything like a patch.

The idea is this: make Proc#freeze snapshot all bindings.

Essentially, telling a Proc to freeze would cause all bindings in the proc to be evaluated and replaced with their value at that moment. These values, themselves, would then be frozen, and references to the original code blocks could be released. Requiring an extra method call to accomplish this is slightly inconvenient, but it would keep Ruby 2.0 "backwards compatible" (in quotes because really? does anybody sensible actually abuse proc bindings like this?). The hope would be that eventually everyone would get into the habit of freezing their procs and eventually this could become the default behavior.

I have to admit I haven't had a chance to completely work through all the details of this idea yet. I will say that my ultimate hope is that the following two methods would be equivalent with the same performance in Ruby 2.0:


def traditional
  do_stuff...
end

define_method :meta do
  do_stuff...
end.freeze


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


                <div><span class=3D=22Apple-style-span=22 style=3D=22colo=
r: rgb(160, 160, 168); =22>On Monday, October 24, 2011 at 10:29 PM, Charl=
es Oliver Nutter wrote:</span></div>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div>2011/10/1 SASADA Koichi &lt;<a href=3D=
=22mailto:ko1=40atdot.net=22>ko1=40atdot.net</a>&gt;:<br><blockquote type=
=3D=22cite=22><div>- Remove Proc binding<br></div></blockquote><br>I adde=
d this one. Anyone who has ever attempted to optimize Ruby knows<br>this =
is one of the biggest roadblocks. If any time, any local state<br>can be =
seen by code you've passed a block to, you can't optimize any<br>of that =
code in a way that would make it inaccessible.<br><br>I'd also argue it b=
reaks encapsulation in the same awful way that =22retry=22 did:<br><br>de=
f foo<br>  password =3D get=5Fpassword<br>  transaction do<br>    service=
.auth(password)<br>    service.do=5Fsomething<br>  end<br>end<br><br>...<=
br><br>def transaction(&amp;block) =23 my evil patch<br>  steal=5Fpasswor=
d eval('password', block)<br>end<br><br>Any library that can patch =22tra=
nsaction=22 can see the =22password=22 local.<br>Shouldn't local variable=
 encapsulation be sacred=3F<br><br>Get rid of it.</div></div></span></blo=
ckquote><div><br></div><div>I've had an alternate idea to accomplish some=
thing like a compromise, but I'm still a ways away from having anything l=
ike a patch.</div><div><br></div><div>The idea is this: make Proc=23freez=
e snapshot all bindings.</div><div><br></div><div>Essentially, telling a =
Proc to freeze would cause all bindings in the proc to be evaluated and r=
eplaced with their value at that moment. These values, themselves, would =
then be frozen, and references to the original code blocks could be relea=
sed. Requiring an extra method call to accomplish this is slightly inconv=
enient, but it would keep Ruby 2.0 =22backwards compatible=22 (in quotes =
because really=3F does anybody sensible actually abuse proc bindings like=
 this=3F). The hope would be that eventually everyone would get into the =
habit of freezing their procs and eventually this could become the defaul=
t behavior.</div><div><br></div><div>I have to admit I haven't had a chan=
ce to completely work through all the details of this idea yet. I will sa=
y that my ultimate hope is that the following two methods would be equiva=
lent with the same performance in Ruby 2.0:</div><div><br></div><div><br>=
</div><div>def traditional</div><div>&nbsp; do=5Fstuff...</div><div>end</=
div><div><br></div><div>define=5Fmethod :meta do</div><div>&nbsp; do=5Fst=
uff...</div><div>end.freeze</div><div><br></div><div><br></div><div>Thoug=
hts=3F</div>
            
--4ea64658_2a79ec49_1124--