[Webkit-unassigned] [Bug 28983] WebInspector: Wrap primitive values (as objects) in InspectorController::wrap
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Sep 8 07:15:13 PDT 2009
--- Comment #5 from Pavel Feldman <pfeldman at chromium.org> 2009-09-08 07:15:13 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > > I can imagine other uses within the debugger for the ability to get the
> > > properties of an arbitrary object, so I think this needs to be a 1st class
> > > capability. For instance, I've been thinking of writing some kind of object
> > > explorer where you could see a graphical layout of an object, it's properties,
> > > their properties, etc. Such a tool would also need a way to get a list of
> > > properties of an arbitrary object.
> > No, it would not. There are generic capabilities that would be reused for that.
> > Like dumping object structure in console (by means of dir(object)), allows
> > getting and rendering arbitrary objects. You don't need to write an object
> > explorer - it is already in place.
> I'm suggesting I might want to write an alternative UI to explore objects and
> their properties. I think you're suggesting that no one will ever need this.
> Which is also saying that the presentation can't be separated from the model,
> in terms of getting the properties of an object - there IS only one way to ever
> do this and render the UI.
> I'm guessing that with the new proxy stuff here, there are memory- and
> performance-related impacts to making calls like
> InspectorController.getProperties(); namely, every property that comes back
> over as a proxy will be, for the life of the session, tracked in some kind of
> proxy-handle/object map. Is that the concern with exposing a capability of
> getting the properties from an object? It seems like a pretty basic API that
> you want in your toolkit when building debugging tools. Do we just need to be
> careful when using these APIs? Is there some cleanup we can perform? Do we
> need to add weak support to the JS engines so we can automagically clean up the
> mapping tables?
Getting properties of an object is not a big deal given that you have a valid
ObjectProxy for it. You are right, depending on the object id type, it has
different lifetime. Like evaluation results are cached on the injected script
side and that cache is being cleaned up when console is cleared. So you should
be a bit careful when managing these object proxies.
But that is not the main reason I did not want you to use this API. I think
there should be a limited number of UI primitives that we render
page-side-objects with such as ObjectPropertySection. I think we should stick
to them and make sure they are flexible enough. It was clear to me that
ObjectPropertySection was solving your problem and I sent you a snippet with
the code. If your requirements have changed since then, let us revisit it.
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned