On Wed, Oct 26, 2011 at 12:43 AM, Tim Fe= lgentreff <tim@nada1.d= e> wrote:

On Tue, Oct 25, 2011 at 1:51 P= M, Rocky Bernstein <rockyb@rubyforge.org> wrote:

Does it matter? Some probabl= y would argue it doesn't. I think access to locals on the call stack in= a debugger is nice to have.

That can be accomplished without having bindings open like that, as any Sma= lltalk debugger can demonstrate.

First, le= t me say that I misunderstood exactly what was being proposed.

But that said, I think we are quickly moving into glib territory here. I= 9;m not sure what in smalltalk we are comparing "binding" to and = what other mechanisms there are in smalltalk that do similar things; nor am= I sure what the expectations of "any smalltalk debugger" are.
I talked about access to locals, but I can't think of a debugger th= at has access to locals that doesn't also have the ability to change th= ose locals. =A0 The scheme-like proposal mentioned in Josh's talk might= not provide for the the kind of flexibility that current Ruby debuggers ha= ve.=A0 In his talk, Josh asked for an example of a use where one might take= a binding and modify variables not mentioned in the closure. It is not cle= ar to me that between debugger and user interaction it might not just do th= at. (I too find it hard to "reason" about the dynamic case.)

I feel a=A0 flame war brewing; my intent is/was to point out something = to keep in mind.