From: Rocky Bernstein <rockyb@...>
Date: 2013-01-18T16:11:05+09:00
Subject: [ruby-core:51506] Re: [ruby-trunk - Bug #7702][Open] Remove Proc#binding

--047d7b2eda8b4fbf6604d38aba4b
Content-Type: text/plain; charset=ISO-8859-1

I suspect it would have a negative impact on the ability to write a
debugger.  I seem to recall noting (I think it was from the pry person)
that the equivalent of ruby-debug's binding_n was impossible in 2.0 and
perhaps a patch was added to include it back.

However, given the gap between what is desirable in writing a good debugger
and where things have been going in MRI,  my current view is that there
should be two separate interpreters. In this way, the concerns of good
debugging don't have to run up against the concerns of good security or
performance. And so far, the trend has been that debuggers have been
losing.  What can be done in 1.9 with respect to debugging is not as good
comprehensive as what was available in 1.8. And in 2.0, I am not certain
things will change that much although it appears that things will be
different.

On the other hand, with respect to the two interpreter approach I also do
believe that one should be able debug optimized code -- even if that means
putting more burden on the programmer to understand more of the
transformations, optimizations or run-time behavior of the interpreter.
While one might not guarantee that Proc#binding is available because some
kind of optimization took place, I think it a mistake to remove it in those
cases where it could have been provided by using the same mechanisms that
were in place previously.

On Tue, Jan 15, 2013 at 7:09 PM, jballanc (Joshua Ballanco) <
jballanc@gmail.com> wrote:

>
> Issue #7702 has been reported by jballanc (Joshua Ballanco).
>
> ----------------------------------------
> Bug #7702: Remove Proc#binding
> https://bugs.ruby-lang.org/issues/7702
>
> Author: jballanc (Joshua Ballanco)
> Status: Open
> Priority: Normal
> Assignee:
> Category:
> Target version:
> ruby -v: 2.0.0-preview1
>
>
> =begin
> As discussed in the most recent Ruby implementer's meeting and elsewhere
> over the years, being able to get a handle to the binding of any block/proc
> has a number of problems:
>
> * Code execution after passing a block/proc in unpredictable, as the
> binding of said proc can be used to redefine any local, instance variable,
> method, class, module, etc.
> * Potentially sensitive data can leak out of the scope of a method via a
> proc binding
> * Large object graphs may need to be retained for the lifetime of a proc,
> since any identifier in scope at the time of proc creation must remain live
> in the event that the binding of the proc is used to evaluate code
>
> Additionally, removal of Proc#binding would enable a number of very useful
> optimizations and performance improvements.
> =end
>
>
>
> --
> http://bugs.ruby-lang.org/
>
>

--047d7b2eda8b4fbf6604d38aba4b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I suspect it would have a negative impact on the ability to write a debugge=
r.=A0 I seem to recall noting (I think it was from the pry person)=A0 that =
the equivalent of ruby-debug&#39;s binding_n was impossible in 2.0 and perh=
aps a patch was added to include it back.<br>
<br>However, given the gap between what is desirable in writing a good debu=
gger and where things have been going in MRI,=A0 my current view is that th=
ere should be two separate interpreters. In this way, the concerns of good =
debugging don&#39;t have to run up against the concerns of good security or=
 performance. And so far, the trend has been that debuggers have been losin=
g.=A0 What can be done in 1.9 with respect to debugging is not as good comp=
rehensive as what was available in 1.8. And in 2.0, I am not certain things=
 will change that much although it appears that things will be different.<b=
r>
<br>On the other hand, with respect to the two interpreter approach I also =
do believe that one should be able debug optimized code -- even if that mea=
ns putting more burden on the programmer to understand more of the transfor=
mations, optimizations or run-time behavior of the interpreter. While one m=
ight not guarantee that Proc#binding is available because some kind of opti=
mization took place, I think it a mistake to remove it in those cases where=
 it could have been provided by using the same mechanisms that were in plac=
e previously.<br>
<br><div class=3D"gmail_quote">On Tue, Jan 15, 2013 at 7:09 PM, jballanc (J=
oshua Ballanco) <span dir=3D"ltr">&lt;<a href=3D"mailto:jballanc@gmail.com"=
 target=3D"_blank">jballanc@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<br>
Issue #7702 has been reported by jballanc (Joshua Ballanco).<br>
<br>
----------------------------------------<br>
Bug #7702: Remove Proc#binding<br>
<a href=3D"https://bugs.ruby-lang.org/issues/7702" target=3D"_blank">https:=
//bugs.ruby-lang.org/issues/7702</a><br>
<br>
Author: jballanc (Joshua Ballanco)<br>
Status: Open<br>
Priority: Normal<br>
Assignee:<br>
Category:<br>
Target version:<br>
ruby -v: 2.0.0-preview1<br>
<br>
<br>
=3Dbegin<br>
As discussed in the most recent Ruby implementer&#39;s meeting and elsewher=
e over the years, being able to get a handle to the binding of any block/pr=
oc has a number of problems:<br>
<br>
* Code execution after passing a block/proc in unpredictable, as the bindin=
g of said proc can be used to redefine any local, instance variable, method=
, class, module, etc.<br>
* Potentially sensitive data can leak out of the scope of a method via a pr=
oc binding<br>
* Large object graphs may need to be retained for the lifetime of a proc, s=
ince any identifier in scope at the time of proc creation must remain live =
in the event that the binding of the proc is used to evaluate code<br>

<br>
Additionally, removal of Proc#binding would enable a number of very useful =
optimizations and performance improvements.<br>
=3Dend<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
--<br>
<a href=3D"http://bugs.ruby-lang.org/" target=3D"_blank">http://bugs.ruby-l=
ang.org/</a><br>
<br>
</font></span></blockquote></div><br>

--047d7b2eda8b4fbf6604d38aba4b--