On Feb 24, 2012, at 10:27 AM, Adam Barth wrote:

> 2012/2/24 Maciej Stachowiak <[email protected]>:
>> 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.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to