On Fri, Feb 24, 2012 at 11:50 AM, Maciej Stachowiak <m...@apple.com> wrote: > On Feb 24, 2012, at 10:27 AM, Adam Barth wrote: >> 2012/2/24 Maciej Stachowiak <m...@apple.com>: >>> I too am surprised that HTML-related APIs would be refactored as a result >>> of modularization. This change may be justifiable on its own merits, but it >>> doesn't seem like a logical part of a project to make self-contained >>> features more modular. At the very least, to avoid confusion, changes like >>> that should be kept clearly separate from the modularization effort, or >>> else, someone could explain the relationship if there is one and its not >>> obvious. >> >> Fair enough. I've detached those bugs from the larger meta bug. >> >> These patches have a different goal than the other patches attached to >> that meta bug. Much in the same way that we've moved code out of >> Frame.h over time, these patches are intended to make DOMWindow.idl >> more readable. The net result will (hopefully!) be a file that's more >> focused on concerns that actually relate to DOMWindow (e.g., >> name/closed/opener/parent/top) rather than a dumping ground for every >> random thing that needs to be in the global scope. >> >> In retrospect, we should have presented this work separately so folks >> could have discussed its merits separately. I think we got tied up in >> the implementation detail that the same mechanism makes both projects >> possible. > > I think this case is a little different than Frame.h, because with Frame, we > can actually move related methods to separate objects, thus actually > splitting up the interface. This creates an actual separation of concerns in > the code if done right, not just a file split. I'm not sure that having > multiple files which actually all form a single interface is equally > beneficial. It doesn't seem hugely worse, but it does not seem obviously > better to me either.
It's quite analogous to Frame.h in the sense that this mechanism also lets us move related methods to a separate object. Consider a case such as <http://trac.webkit.org/browser/trunk/Source/WebCore/fileapi/DOMWindowFileSystem.idl>. When we moved webkitRequestFileSystem from DOMWindow.idl to DOMWindowFileSystem.idl, the code for webkitRequestFileSystem moved from DOMWindow.cpp to <http://trac.webkit.org/browser/trunk/Source/WebCore/fileapi/DOMWindowFileSystem.cpp#L53>, separating these concerns from DOMWindow. In the case of <http://trac.webkit.org/browser/trunk/Source/WebCore/html/DOMWindowHTML.idl>, the C++ code that backs those interfaces is already in Source/WebCore/html. The net result is 100 less lines of "noise" in DOMWindow.idl. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
