[ruby-core:40408] Re: 2.0 feature questionnaire

On Wed, Oct 26, 2011 at 1:14 AM, Rocky Bernstein <[e-mail]> wro=
te:
> First, let me say that I misunderstood exactly what was being proposed.
>
> But that said, I think we are quickly moving into glib territory here. I'=
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 w=
hat
> the expectations of "any smalltalk debugger" are.
>
> I talked about access to locals, but I can't think of a debugger that has
> access to locals that doesn't also have the ability to change those local=
s.
> =C2=A0 The scheme-like proposal mentioned in Josh's talk might not provid=
e for
> the the kind of flexibility that current Ruby debuggers have.=C2=A0 In hi=
s talk,
> Josh asked for an example of a use where one might take a binding and mod=
ify
> variables not mentioned in the closure. It is not clear to me that betwee=
n
> debugger and user interaction it might not just do that. (I too find it h=
ard
> to "reason" about the dynamic case.)

As you probably know, I'm still of the opinion that debug time and
runtime have completely different characteristics. Expecting that
debug-time binding access (frame access, local variable modification,
etc) should be available at normal runtime is unreasonable...it's not
possible to do this without killing many, many optimizations. You and
I discussed that those optimizations could still be active and
debuggers would just lose functionality...but I'm not sure I see that
being useful. If JRuby eliminated all local variables for a given
method and the debugger was unable to see them, what use is the local
variable feature of the debugger? I'm still of the opinion that
debugging will almost always be most useful in a mode that limits
optimizations normally invisible to the user, so we're talking about a
completely different mode of execution where full-system binding
access may be just fine.

In any case, this is a bit off topic. All I want is the ability to be
able to statically inspect a method and the blocks it contains and
know exactly how much of the enclosing state it needs access to. That
opens up a broad range of optimizations, like reducing the overhead of
accessing closed-over variables.

And of course there's the encapsulation problems :)

- Charlie