76423 2012-01-16 20:59:09 -0800 [Meta] Refactoring Internals 2012-07-25 22:56:44 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 88508 76424 76426 88499 1 morrita morrita abarth cmarcelo dbates dglazkov dominicc donggwan.kim dpranke jesus rakuco rniwa skyul oldest_to_newest 536869 0 morrita 2012-01-16 20:59:09 -0800 The number of Internals API becomes too much API. These API should be reassigned into multiple smaller objects. My current plan is to introduce: - SettingsInternals - ElementInternals - NodeInternals - DocumentInternals 536872 1 dominicc 2012-01-16 21:05:55 -0800 Is the plan to arrange them like: internals.settings.m() internals.element.n() etc.? I think this is neat, because existing if (window.internals) tests work, and you can slowly migrate API from internals to internals.x. Why not keep all of the DOM-related ones together, eg instead of internals.element, internals.node and internals.document just have internals.dom? It’s shorter and even if the API of internals.dom is large, it is pretty strongly related. Need to think less which specific part of internals I need for a given testing task. 537470 2 morrita 2012-01-17 17:15:52 -0800 (In reply to comment #1) > Why not keep all of the DOM-related ones together, eg instead of internals.element, internals.node and internals.document just have internals.dom? It’s shorter and even if the API of internals.dom is large, it is pretty strongly related. Need to think less which specific part of internals I need for a given testing task. Well. window.internals.dom might be better. What I thought is internals.element(x).foo(). But per element instance is possibly too much. 537478 3 dominicc 2012-01-17 17:20:10 -0800 (In reply to comment #2) > (In reply to comment #1) > > Why not keep all of the DOM-related ones together, eg instead of internals.element, internals.node and internals.document just have internals.dom? It’s shorter and even if the API of internals.dom is large, it is pretty strongly related. Need to think less which specific part of internals I need for a given testing task. > > Well. window.internals.dom might be better. > What I thought is internals.element(x).foo(). Wrappers! Could be convenient. > But per element instance is possibly too much. I think per-instance is OK. I was worried if you have Node and Element I am going to need to keep track of which wrapper has the API I want. (Unless Element is a superset of Node API?) Looking at the internals API it looks like it splits into Document and Element, and there is no node. So maybe it is OK. 561300 4 rniwa 2012-02-21 15:46:12 -0800 (In reply to comment #2) > (In reply to comment #1) > > Why not keep all of the DOM-related ones together, eg instead of internals.element, internals.node and internals.document just have internals.dom? It’s shorter and even if the API of internals.dom is large, it is pretty strongly related. Need to think less which specific part of internals I need for a given testing task. > > Well. window.internals.dom might be better. > What I thought is internals.element(x).foo(). Hm... I'm worried that this would make the test code less obvious. e.g. you can do something like: var x = internals.element(x); ... x.foo(); // Wait, where did foo come from?