It seems reasonable to keep mock objects that act solely as the back end to platform/ classes in platform/. I believe Sam was commenting specifically on mock objects that know about things outside platform/. The specific example given was not (afaict) a client interfance. I think it's reasonable to segregate all the mock objects, since their dependencies in general are not limited to platform/, and it doesn't seem great to scatter them around the tree. Refactoring some of the mock objects to reduce dependencies is another possibility, but probably more complicated. It would be good to fix the layering in the meantime as Sam suggested.
- Maciej On Nov 26, 2010, at 11:20 AM, Adam Barth wrote: > Originally, I thought it made sense to mock out pieces of the platform > abstraction that didn't exist in all ports (e.g., GPS sensors). I'm > not sure why you'd want to mock out a client interface. Can't you > just implement the client interface in DRT? > > Adam > > > On Fri, Nov 26, 2010 at 10:33 AM, Sam Weinig <[email protected]> wrote: >> Just a general question as to why the decision was made to put the mock >> implementation classes (DeviceOrientationClientMock, GeolocationServiceMock >> and SpeechInputClientMock) beneath WebCore/platform. WebCore/platform is >> not supposed to know about classes outside of WebCore/platform in WebCore >> (such as DeviceOrientationController) and this seems to be perpetuating the >> laying violation. Perhaps a top-level WebCore/mock/ would be preferable. >> - Sam >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
