On Feb 28, 2012, at 11:25 AM, Darin Fisher wrote: > On Tue, Feb 28, 2012 at 11:11 AM, Alexey Proskuryakov <a...@webkit.org> wrote: > > Having read the wiki page, I'm even more unhappy with the approach that has > been taken than I used to be. In fact, it is harmful even to the goals of the > refactoring. > > If a single #ifdefed line in DOMWindow.idl is a burden for development, what > about adding several new files to each and every build system, and > maintaining these multiple files into perpetuity? That's much more work for > everyone - port maintainers, core developers, and feature developers. The > likelihood of repeated breakage is higher with the need to maintain a more > complicated build system. > > Sticking to the concrete example, these lines in WorkerContext.idl are not > really something a WebSocket engineer maintains. It's more important for a > person working on JS bindings and/or on threading, and the need to hunt down > these across many files makes hacking more difficult. How can one even find > an answer to the very practical question of which properties are available on > WorkerContext if these are split across multiple files? > > Is this something the build system could help address? Perhaps a by-product > of the build is or could be a single file that contains everything that will > be exposed on WorkerContext / DOMWindow? > > I know studying a generated file is never as nice as studying a source file, > but perhaps there is a compromise of this sort that could work? > > I guess I'm just a big fan of modularization. It seems helpful to separate > logical units and minimize large "cross roads" files.
The counterpoint is that decorating objects purely from the outside can be a pattern that's hard to understand, when the "decorations" actually affect the behavior of the object being augmented. Sometimes, making the relationship explicit on the receiving end is easier to understand, even if it results in a "cross roads" file. I'm not really sure myself where the tradeoff lies, but I'm a bit wary of applying the pattern everywhere as much as possible. >From the initial mail about modules, I got the (perhaps mistaken) impression >that it would be used only for selected features that had very loose coupling >and were perhaps not even of interest to every port. That seemed like a fine >experiment to try, to see if it actually reduces the impact of these features. But it seems like what is actually happening is wholesale rapid application of this pattern to all of WebCore, including even things that aren't in the Modules directory. So it's starting to seem more like a major restructuring of WebCore than like a lower-impact way of doing new peripheral features. It seems to me that starting on a more limited scale would have a better opportunity to measure WebKit community buy-in. If the main motivation for this project is hackability, then I think it needs to make people feel like hackability is actually improving. Ideally we'd measure that with an incremental step of some kind before applying it everywhere. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
