> On Mon, Sep 17, 2012 at 4:53 AM, Yury Semikhatsky <yu
...@chromium.org>
> wrote:
> > This would require storing references to all objects accessible from the
> > scope chain and may lead to memory leaks caused by DevTools keeping the
> > objects alive. Although I believe the feature can be useful I don't
> think we
> > should blindly store the whole scope chain.
> Rather than storing the references, one could copy them into
> 'representation' objects which only reference other representation
> objects not the heap. The representation for primitives would be
> primitives. Representation of the DOM would be a string like "<input
> type='text'>...". So the result object would be large but it would not
> point outside of itself; as soon as the console is cleared the large
> object would be GC fodder. (This is similar to rendering the object to
> text without actually rendering it).
> For small programs or large closures each representation could be
> larger than the program heap. To reduce the performance impact,
> console.scope() could take a "depth" argument, where leaves at depth
> are rendered to strings. Thus console.depth(1) would give the same
> picture as Brian's blog post but the twistys would all give
> "console.scope rendered at depth 1" or some such.
> jjb
> > Yury
> > On Thu, Sep 13, 2012 at 6:04 AM, Brian Grinstead <
> briangrinst...@gmail.com>
> > wrote:
> >> I've been thinking about a feature that would save me some time when
> >> working with DevTools. The basic idea is that sometimes I just want to
> log
> >> all (or many) of the variables inside of a function, and it can be a
> bit of
> >> work to copy all of the variable names into the console.log() call when
> I
> >> know that I am just going to delete the line afterwards anyway. I would
> >> propose a solution called console.scope() that is similar to
> >> console.trace(), but it logs scope variables instead of the call stack.
> >> I wrote a post detailing this a little more:
> http://www.briangrinstead.com/blog/devtools-feature-request-console-s....
> >> Is there any interest in a feature like this?
