These both sound right to me. 

More generally, I would expect that over time, PAL would likely become a peer 
project to WebCore instead of being inside it, much the same way WTF started 
inside JavaScriptCore and eventually moved outside it in the source tree. In 
the WTF case, it always had a separate top-level namespace.

> On Jan 11, 2017, at 12:27 PM, Antti Koivisto <koivi...@iki.fi> wrote:
> 
> Why is the PAL namespace inside the WebCore namespace? Couldn't it just be a 
> top-level namespace (even if it currently happens to live in the WebCore 
> project)?
> 
> #include <pal/Foo.h> would be more consistent with existing headers than 
> <PAL/Foo.h>.
> 
> 
>   antti
> 
> On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield <mmaxfi...@apple.com 
> <mailto:mmaxfi...@apple.com>> wrote:
> After 18 months of no progress, Don Olmstead and I are getting the band back 
> together!
> 
> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 
> <https://bugs.webkit.org/show_bug.cgi?id=143358> which incorporates feedback 
> from many different stakeholders (and as such, the direction is a little 
> different than where I was going with this in the beginning).
> 
> First of all, this isn’t a new project; instead, it’s a new target inside the 
> WebCore project. The target creates a static library which gets linked into 
> WebCore, which means that the enforcement mechanism can’t be done by the 
> linker. Instead, the layering will be enforced by a Python script, triggered 
> as an extra build step, which checks the symbol names inside the .a file as 
> well as #include directives in source code.
> 
> We opted for WebCore to include files using “#include <PAL/Foo.h>” instead of 
> just including Foo.h. Similarly, we are putting symbols inside the PAL 
> namespace, which is a child of the WebCore namespace. Therefore, inside 
> WebCore, you use PAL things by specifying “PAL::Foo”.
> 
> The first thing to move into PAL is the “crypto” subfolder, which is a good 
> candidate because it’s small, simple, yet also has platform-dependent 
> implementations.
> 
> We would love your feedback on this approach to help make the dream a reality!
> 
> Thanks,
> Myles and Don
> 
>> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough <barraclo...@apple.com 
>> <mailto:barraclo...@apple.com>> wrote:
>> 
>>> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak <m...@apple.com 
>>> <mailto:m...@apple.com>> wrote:
>>> 
>>> Web Abstraction Toolbox (it’s hard to tell the difference between wat and 
>>> WTF sometimes…)
>> 
>> +1
>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to