<div class="gmail_quote">On Fri, Nov 18, 2011 at 11:21 AM, Adam Barth <span dir="ltr"><<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

On Fri, Nov 18, 2011 at 2:06 AM, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>> wrote: </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

What's the benefit of this re-org?</blockquote>The benefit is mostly to improve the hackability of WebKit by grouping<br>
related code together and separating unrelated code.  My hope is that<br>
the code in the "Features" directory will become more self-contained<br>
over time, helping us increase the functionality provided by WebKit<br>
with less implementation complexity.<br></blockquote><div><br></div><div>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">These moves should be less disruptive than the Source move.  The total<br>
volume of code is an order of magnitude less, and the changes can be<br>
made in smaller increments.<br></blockquote><div><br></div><div>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">One good rule of thumb is if you've creating a bunch of files (i.e., a<br>
decent block code) behind an ENABLE ifdef, then it should probably go<br>
in the Features directory, especially if it corresponds to a<br>
"standalone" specification, e.g., from the WebApps working group.<br></blockquote><div><br></div><div>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?</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
One of the benefits of this approach is to encourage the folks writing<br>
these blocks of code to make them more self-contained so that the core<br>
part of the engine has fewer ifdefs.<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>Having said that, I re-iterate my agreement that moving manual-tests and platform out of WebCore would be a clear improvement.</div><div><br></div><div>- Ryosuke</div><div><br></div></div>