[webkit-dev] Cleaning up directories in WebCore
I've been looking for ways to improve the hackability of WebCore, and one thing that's been bothering me is the organization of our files. It seems like we're due for a bit of fall cleaning for directories. We've talked about some of these ideas before, but I wanted to put them all in one email so we can see the big picture. Below is a concrete proposal for moving some directories around. In this approach, we'll have a Features directory to contain logically self-contained features, like WebAudio and MediaStream, that are part of the engine but that aren't tightly coupled with the DOM, Layout, or Rendering. We'd also have a new events directory in dom to contain the large number of event-related files that we've accreted. The history directory would move into page (we could actually merge these directories because history is so small). Finally, manual-tests and platform would move out of WebCore entirely. Features/ -- New folder for (roughly) self-contained features notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ manual-tests/ -- Move outside of Source dom/ events/ -- New folder for the 106 files that match dom/*Event* page/ history/ -- Moved from top-level platform/ -- Move to Source/Platform The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. Please let me know if you have any thoughts. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
What's the benefit of this re-org? Is it really worth the trouble to move these files around? This would mean that we may need to navigate multiple pages on trac to see revision logs. Other tools may suffer from such file moves as well. I remember I had to create new git checkout when Source move happened. Also, moving inspector, notifications, etc... under Features would mean that folks working on those components now need to type at last 2-3 more characters even with tab completion to find their files. Isn't that worse than the current situation? And how would one decide whether a directory belongs to WebCore vs. WebCore/Features? Though I do agree that moving manual-test out of Source/WebCore seems like a good idea. It should probably live at trunk/ManualTests. - Ryosuke On Fri, Nov 18, 2011 at 1:51 AM, Adam Barth aba...@webkit.org wrote: I've been looking for ways to improve the hackability of WebCore, and one thing that's been bothering me is the organization of our files. It seems like we're due for a bit of fall cleaning for directories. We've talked about some of these ideas before, but I wanted to put them all in one email so we can see the big picture. Below is a concrete proposal for moving some directories around. In this approach, we'll have a Features directory to contain logically self-contained features, like WebAudio and MediaStream, that are part of the engine but that aren't tightly coupled with the DOM, Layout, or Rendering. We'd also have a new events directory in dom to contain the large number of event-related files that we've accreted. The history directory would move into page (we could actually merge these directories because history is so small). Finally, manual-tests and platform would move out of WebCore entirely. Features/ -- New folder for (roughly) self-contained features notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ manual-tests/ -- Move outside of Source dom/ events/ -- New folder for the 106 files that match dom/*Event* page/ history/ -- Moved from top-level platform/ -- Move to Source/Platform The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. Please let me know if you have any thoughts. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
I also agree with moving Platform out. That would make the dependencies easier to understand and hopefully avoid more layering violations. Kenneth On Fri, Nov 18, 2011 at 11:06 AM, Ryosuke Niwa rn...@webkit.org wrote: What's the benefit of this re-org? Is it really worth the trouble to move these files around? This would mean that we may need to navigate multiple pages on trac to see revision logs. Other tools may suffer from such file moves as well. I remember I had to create new git checkout when Source move happened. Also, moving inspector, notifications, etc... under Features would mean that folks working on those components now need to type at last 2-3 more characters even with tab completion to find their files. Isn't that worse than the current situation? And how would one decide whether a directory belongs to WebCore vs. WebCore/Features? Though I do agree that moving manual-test out of Source/WebCore seems like a good idea. It should probably live at trunk/ManualTests. - Ryosuke On Fri, Nov 18, 2011 at 1:51 AM, Adam Barth aba...@webkit.org wrote: I've been looking for ways to improve the hackability of WebCore, and one thing that's been bothering me is the organization of our files. It seems like we're due for a bit of fall cleaning for directories. We've talked about some of these ideas before, but I wanted to put them all in one email so we can see the big picture. Below is a concrete proposal for moving some directories around. In this approach, we'll have a Features directory to contain logically self-contained features, like WebAudio and MediaStream, that are part of the engine but that aren't tightly coupled with the DOM, Layout, or Rendering. We'd also have a new events directory in dom to contain the large number of event-related files that we've accreted. The history directory would move into page (we could actually merge these directories because history is so small). Finally, manual-tests and platform would move out of WebCore entirely. Features/ -- New folder for (roughly) self-contained features notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ manual-tests/ -- Move outside of Source dom/ events/ -- New folder for the 106 files that match dom/*Event* page/ history/ -- Moved from top-level platform/ -- Move to Source/Platform The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. Please let me know if you have any thoughts. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
SGTM. manual-tests is a no-brainer for sure. On Fri, Nov 18, 2011 at 1:51 AM, Adam Barth aba...@webkit.org wrote: I've been looking for ways to improve the hackability of WebCore, and one thing that's been bothering me is the organization of our files. It seems like we're due for a bit of fall cleaning for directories. We've talked about some of these ideas before, but I wanted to put them all in one email so we can see the big picture. Below is a concrete proposal for moving some directories around. In this approach, we'll have a Features directory to contain logically self-contained features, like WebAudio and MediaStream, that are part of the engine but that aren't tightly coupled with the DOM, Layout, or Rendering. We'd also have a new events directory in dom to contain the large number of event-related files that we've accreted. The history directory would move into page (we could actually merge these directories because history is so small). Finally, manual-tests and platform would move out of WebCore entirely. Features/ -- New folder for (roughly) self-contained features notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ manual-tests/ -- Move outside of Source dom/ events/ -- New folder for the 106 files that match dom/*Event* page/ history/ -- Moved from top-level platform/ -- Move to Source/Platform The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. Please let me know if you have any thoughts. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
I agree. My personal favorite is the moving out of the side-loaded features. This looks like a great way to add clarity to what WebCore really means. :DG On Fri, Nov 18, 2011 at 2:19 AM, Eric Seidel e...@webkit.org wrote: SGTM. manual-tests is a no-brainer for sure. On Fri, Nov 18, 2011 at 1:51 AM, Adam Barth aba...@webkit.org wrote: I've been looking for ways to improve the hackability of WebCore, and one thing that's been bothering me is the organization of our files. It seems like we're due for a bit of fall cleaning for directories. We've talked about some of these ideas before, but I wanted to put them all in one email so we can see the big picture. Below is a concrete proposal for moving some directories around. In this approach, we'll have a Features directory to contain logically self-contained features, like WebAudio and MediaStream, that are part of the engine but that aren't tightly coupled with the DOM, Layout, or Rendering. We'd also have a new events directory in dom to contain the large number of event-related files that we've accreted. The history directory would move into page (we could actually merge these directories because history is so small). Finally, manual-tests and platform would move out of WebCore entirely. Features/ -- New folder for (roughly) self-contained features notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ manual-tests/ -- Move outside of Source dom/ events/ -- New folder for the 106 files that match dom/*Event* page/ history/ -- Moved from top-level platform/ -- Move to Source/Platform The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. Please let me know if you have any thoughts. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
On Nov 18, 2011, at 1:51 AM, Adam Barth wrote: Features/ -- New folder for (roughly) self-contained features I like the concept, but not the name. I’ll try to think on this and suggest a name I like better than “features”. notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ Not sure these are all the best names. In some cases we include the “web” prefix from the name of the specification and in other cases we omit it. But maybe these match ENABLE names that are already long-established. manual-tests/ -- Move outside of Source Seems clearly right and different from the other suggestions; since these files are not involved in builds I think we can easily do this move sooner than other moves. dom/ events/ -- New folder for the 106 files that match dom/*Event* Seems OK, but sort of cuts against the feature organization. This could separate What about “device motion”, “device orientation”, “micro data”, “messages”, and “clipboard”? Many of these don’t seem to fit well into the dom directory even though the code is all there. page/ history/ -- Moved from top-level The name history is ambiguous. Is it the back/forward list (called “history” from the point of view of JavaScript, but something we are careful to never call history in WebKit API on Mac at least) or global history (the visited link machinery)? platform/ -- Move to Source/Platform Good important idea. The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. I think it’s helpful for at least one or two additional people to review a list of the files to move before we do each of these moves. I think one useful planning tool would be a list of directories and numbers of files in them. Logical organization is important, but size is also relevant to judge the benefits of a new possible organization. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
On Fri, Nov 18, 2011 at 2:06 AM, Ryosuke Niwa rn...@webkit.org wrote: What's the benefit of this re-org? The benefit is mostly to improve the hackability of WebKit by grouping related code together and separating unrelated code. My hope is that the code in the Features directory will become more self-contained over time, helping us increase the functionality provided by WebKit with less implementation complexity. Is it really worth the trouble to move these files around? This would mean that we may need to navigate multiple pages on trac to see revision logs. Other tools may suffer from such file moves as well. I remember I had to create new git checkout when Source move happened. These moves should be less disruptive than the Source move. The total volume of code is an order of magnitude less, and the changes can be made in smaller increments. Also, moving inspector, notifications, etc... under Features would mean that folks working on those components now need to type at last 2-3 more characters even with tab completion to find their files. Isn't that worse than the current situation? I don't see that as a big cost, but perhaps I'm spoiled by using TextMate and Xcode, which make it easy to navigate files. And how would one decide whether a directory belongs to WebCore vs. WebCore/Features? One good rule of thumb is if you've creating a bunch of files (i.e., a decent block code) behind an ENABLE ifdef, then it should probably go in the Features directory, especially if it corresponds to a standalone specification, e.g., from the WebApps working group. One of the benefits of this approach is to encourage the folks writing these blocks of code to make them more self-contained so that the core part of the engine has fewer ifdefs. Though I do agree that moving manual-test out of Source/WebCore seems like a good idea. It should probably live at trunk/ManualTests. That sounds like the place we should start. On Fri, Nov 18, 2011 at 2:17 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I also agree with moving Platform out. That would make the dependencies easier to understand and hopefully avoid more layering violations. That's also the hardest part, which means I'll probably do it last. :) On Fri, Nov 18, 2011 at 9:54 AM, Darin Adler da...@apple.com wrote: On Nov 18, 2011, at 1:51 AM, Adam Barth wrote: Features/ -- New folder for (roughly) self-contained features I like the concept, but not the name. I’ll try to think on this and suggest a name I like better than “features”. Yeah, features is too general a name. Here are some more ideas: - Modules (emphasizing that these are standalone and can be added or removed from the build) - notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ Not sure these are all the best names. In some cases we include the “web” prefix from the name of the specification and in other cases we omit it. But maybe these match ENABLE names that are already long-established. Another option is to align them more closely with the TR name of the specification they implement. That would make it easier to understand the connection with their specifications. manual-tests/ -- Move outside of Source Seems clearly right and different from the other suggestions; since these files are not involved in builds I think we can easily do this move sooner than other moves. Yes. I'll do this first. dom/ events/ -- New folder for the 106 files that match dom/*Event* Seems OK, but sort of cuts against the feature organization. This could separate What about “device motion”, “device orientation”, “micro data”, “messages”, and “clipboard”? Many of these don’t seem to fit well into the dom directory even though the code is all there. I was worried that approach would create directories with too few files in them. page/ history/ -- Moved from top-level The name history is ambiguous. Is it the back/forward list (called “history” from the point of view of JavaScript, but something we are careful to never call history in WebKit API on Mac at least) or global history (the visited link machinery)? It's the BackForward list and the PageCache. It's pretty small. Maybe we should just merge it with page or name it backforward? platform/ -- Move to Source/Platform Good important idea. The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. I think it’s helpful for at least one or two additional people to review a list of the files to move before we do each of these moves. That sounds like something that's best done in the bug tracker. Once the discussion here as settled down, I'll file bugs about each of these with a list of files and solicit
Re: [webkit-dev] Cleaning up directories in WebCore
On Fri, Nov 18, 2011 at 1:51 AM, Adam Barth aba...@webkit.org wrote: I've been looking for ways to improve the hackability of WebCore, and one thing that's been bothering me is the organization of our files. It seems like we're due for a bit of fall cleaning for directories. We've talked about some of these ideas before, but I wanted to put them all in one email so we can see the big picture. Below is a concrete proposal for moving some directories around. In this approach, we'll have a Features directory to contain logically self-contained features, like WebAudio and MediaStream, that are part of the engine but that aren't tightly coupled with the DOM, Layout, or Rendering. One comment regarding Web Audio since Chris Rogers is on vacation. This particular API is in the process of being better integrated with other DOM elements -- so, for example, a video or audio tag can be used as a Web Audio source node. It seems to me that moving its sources out of WebCore will make it more difficult to achieve this integration, especially if new rules are instituted about dependencies between Source/WebCore/ and Source/Features/ . Is separate compilation of WebCore/ and Features/ a goal or non-goal? The same comment applies to many of the other directories under consideration like workers/. For this reason I wonder whether smaller and less traumatic reorganizations would be better in the long run. Separating out platform/ sounds great, though. -Ken We'd also have a new events directory in dom to contain the large number of event-related files that we've accreted. The history directory would move into page (we could actually merge these directories because history is so small). Finally, manual-tests and platform would move out of WebCore entirely. Features/ -- New folder for (roughly) self-contained features notifications/ storage/ fileapi/ webaudio/ mediastream/ workers/ websockets/ inspector/ manual-tests/ -- Move outside of Source dom/ events/ -- New folder for the 106 files that match dom/*Event* page/ history/ -- Moved from top-level platform/ -- Move to Source/Platform The html and page directories also contain a bunch of unrelated files (presumably because they're attractive locations for folks to add files). Once we do the directory moves above, I'll send out another proposal for cleaning up those directories a bit. Please let me know if you have any thoughts. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
On Fri, Nov 18, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: On Fri, Nov 18, 2011 at 2:06 AM, Ryosuke Niwa rn...@webkit.org wrote: What's the benefit of this re-org? The benefit is mostly to improve the hackability of WebKit by grouping related code together and separating unrelated code. My hope is that the code in the Features directory will become more self-contained over time, helping us increase the functionality provided by WebKit with less implementation complexity. Okay. Making each component self-contained by itself seems like a good idea but I'm not sure if re-organizing directories and files is the best way to accomplish this. For example, each component can still have lots of bad dependencies within each file since we don't control header inclusion per directory. These moves should be less disruptive than the Source move. The total volume of code is an order of magnitude less, and the changes can be made in smaller increments. Still, if I see a crash in shipped version of Chrome, then I have to remember to map between different paths, which will be a huge cognitive overhead for the next couple of months if we start the move now. Also, there are zillion WebKit crash bugs with stack trace. Those file paths need to be moved as well. In addition, all work-in-progress patches and local git branches will likely to conflict with these moves. One good rule of thumb is if you've creating a bunch of files (i.e., a decent block code) behind an ENABLE ifdef, then it should probably go in the Features directory, especially if it corresponds to a standalone specification, e.g., from the WebApps working group. Hm... what happens if we decide to enable it on all platforms and get rid of the ENABLE flag? Should we then move those files to a different directory? One of the benefits of this approach is to encourage the folks writing these blocks of code to make them more self-contained so that the core part of the engine has fewer ifdefs. I agree this is a good goal. I'm yet convinced that the proposal directory reorg would accomplish this though. Perhaps a better way to accomplish this is to introduce some sort of header inclusion rules. Having said that, I re-iterate my agreement that moving manual-tests and platform out of WebCore would be a clear improvement. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
On Fri, Nov 18, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Features/ notifications/ (8 files) storage/ (195 files) fileapi/ (115 files) webaudio/ (103 files) mediastream/ (28 files; under active development) workers/ (43 files) websockets/ (20 files) inspector/ (426 files) Along that change, what about moving some of the tests to follow the same directory structures as the Features/Modules?: LayoutTests/Features/notifications, etc This would make it easier to find a good subset of tests to run while developing. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
On Fri, Nov 18, 2011 at 1:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Nov 18, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: On Fri, Nov 18, 2011 at 2:06 AM, Ryosuke Niwa rn...@webkit.org wrote: What's the benefit of this re-org? The benefit is mostly to improve the hackability of WebKit by grouping related code together and separating unrelated code. My hope is that the code in the Features directory will become more self-contained over time, helping us increase the functionality provided by WebKit with less implementation complexity. Okay. Making each component self-contained by itself seems like a good idea but I'm not sure if re-organizing directories and files is the best way to accomplish this. For example, each component can still have lots of bad dependencies within each file since we don't control header inclusion per directory. These moves should be less disruptive than the Source move. The total volume of code is an order of magnitude less, and the changes can be made in smaller increments. Still, if I see a crash in shipped version of Chrome, then I have to remember to map between different paths, which will be a huge cognitive overhead for the next couple of months if we start the move now. Also, there are zillion WebKit crash bugs with stack trace. Those file paths need to be moved as well. In addition, all work-in-progress patches and local git branches will likely to conflict with these moves. We move files around all the time. If we're afraid to move files for these reasons, we'll be stuck with bad organizational choices we made in the distant past. WebKit's philosophy is to think of the future as large, so the future benefits of these sorts of changes often outweigh the transition costs. One good rule of thumb is if you've creating a bunch of files (i.e., a decent block code) behind an ENABLE ifdef, then it should probably go in the Features directory, especially if it corresponds to a standalone specification, e.g., from the WebApps working group. Hm... what happens if we decide to enable it on all platforms and get rid of the ENABLE flag? Should we then move those files to a different directory? We should keep these files in those directories. The looser coupling is valuable even for always on features. One of the benefits of this approach is to encourage the folks writing these blocks of code to make them more self-contained so that the core part of the engine has fewer ifdefs. I agree this is a good goal. I'm yet convinced that the proposal directory reorg would accomplish this though. Perhaps a better way to accomplish this is to introduce some sort of header inclusion rules. I've done some analysis of header inclusion dependencies, and they're actually pretty good for these directories. The main issues at the moment are hub classes like Page, Frame, and Document, which need to be touched by many features. One of the things I'm planning to do is remove more ifdefs from these files, which, as a side effect, will improve the dependencies. Having said that, I re-iterate my agreement that moving manual-tests and platform out of WebCore would be a clear improvement. Thanks. On Fri, Nov 18, 2011 at 2:04 PM, Benjamin Poulain benja...@webkit.org wrote: Along that change, what about moving some of the tests to follow the same directory structures as the Features/Modules?: LayoutTests/Features/notifications, etc This would make it easier to find a good subset of tests to run while developing. I agree that cleaning up the organization of the LayoutTests would be valuable. There's been some discussion of moving the conformance tests into some recognizable place so folks can know that certain tests are from, for example, W3C conformance suites. We also have this fast directory, which is pretty meaningless at this point. If you're interested in working on this, I'd encourage you look at the tests we currently have and send a proposal to webkit-dev for how you'd like to clean them up. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
On Fri, Nov 18, 2011 at 2:27 PM, Adam Barth aba...@webkit.org wrote: On Fri, Nov 18, 2011 at 1:47 PM, Ryosuke Niwa rn...@webkit.org wrote: Still, if I see a crash in shipped version of Chrome, then I have to remember to map between different paths, which will be a huge cognitive overhead for the next couple of months if we start the move now. Also, there are zillion WebKit crash bugs with stack trace. Those file paths need to be moved as well. In addition, all work-in-progress patches and local git branches will likely to conflict with these moves. We move files around all the time. If we're afraid to move files for these reasons, we'll be stuck with bad organizational choices we made in the distant past. WebKit's philosophy is to think of the future as large, so the future benefits of these sorts of changes often outweigh the transition costs. Sure. But the question is whether doing this re-org will benefit us in the end or not. I don't think we can always assume any re-org is good. One of the benefits of this approach is to encourage the folks writing these blocks of code to make them more self-contained so that the core part of the engine has fewer ifdefs. I agree this is a good goal. I'm yet convinced that the proposal directory reorg would accomplish this though. Perhaps a better way to accomplish this is to introduce some sort of header inclusion rules. I've done some analysis of header inclusion dependencies, and they're actually pretty good for these directories. The main issues at the moment are hub classes like Page, Frame, and Document, which need to be touched by many features. One thing I wanted to do is separate those hub part of Page, Frame, and Document into PageBase, FrameBase, and DocumentBase. (Or use Hub that the word has been coined). This has a nice side-effect of reducing the header file dependency and possibly reducing the compilation time. One of the things I'm planning to do is remove more ifdefs from these files, which, as a side effect, will improve the dependencies. Yes, that'll be great. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cleaning up directories in WebCore
On Fri, Nov 18, 2011 at 2:38 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Nov 18, 2011 at 2:27 PM, Adam Barth aba...@webkit.org wrote: We move files around all the time. If we're afraid to move files for these reasons, we'll be stuck with bad organizational choices we made in the distant past. WebKit's philosophy is to think of the future as large, so the future benefits of these sorts of changes often outweigh the transition costs. Sure. But the question is whether doing this re-org will benefit us in the end or not. I don't think we can always assume any re-org is good. Consider it this way: if the re-org doesn't benefit us, we shouldn't do it regardless of these reasons. If it does, these reasons should not stop us. Therefore, I don't think we need to spend a lot of time thinking about them -- it is enough to acknowledge that re-orgs have nonzero cost in general. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
