Re: [webkit-dev] Compile times and class-scoped enums

[Jer Noble via webkit-dev]

> On Jan 23, 2023, at 11:05 AM, Geoffrey Garen  wrote:
> 
>>> However, this change requires moving class-scoped enums out into the 
>>> namespace scope.
>> 
>> Seems worthwhile. Doesn’t seem to me like it would have far reaching effects.
> 
> I agree.
> 
>> +using Type = DOMAudioSessionType;
> 
> Did you do this to make the patch smaller, or do you prefer this style?

Yes to both. IMO, there’s nothing inherently wrong with having an enum scoped 
to a class apart from that makes it impossible to forward declare. If there was 
some language supported mechanism to forward-declare class-scoped enums, we’d 
probably just do that instead. So, this pattern of declaring the enum outside 
of a class and pulling it into the class with a using declaration is a bit 
ugly, insofar as it pollutes the global namespace, but it does allow you to 
continue to use the type as if it were file scoped.

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

[webkit-dev] Compile times and class-scoped enums

[Jer Noble via webkit-dev]

Hi all!

I’ve noticed that compile times for the WebKit project have started creeping up 
again, so I and a few other WebKit contributors started looking into possible 
compile time improvements using the tools listed in 
. One cause of long 
compile times is when a commonly-included header (like Document.h) includes 
other headers (which include other headers, ad nauseam). Whereas much of the 
time those includes can be avoided by forward declaring types, for types 
(specifically enums) scoped within classes, this is impossible.

I attempted to address this in , 
which (on this machine) reduces the total compile time of Document.h in the 
WebCore project from about 1000s to about 200s.

However, this change requires moving class-scoped enums out into the namespace 
scope. E.g.:

> diff --git a/Source/WebCore/Modules/audiosession/DOMAudioSession.h 
> b/Source/WebCore/Modules/audiosession/DOMAudioSession.h
> index 01bf6960d3a4..d84e1eae78d5 100644
> --- a/Source/WebCore/Modules/audiosession/DOMAudioSession.h
> +++ b/Source/WebCore/Modules/audiosession/DOMAudioSession.h
> @@ -36,14 +36,17 @@
>  
>  namespace WebCore {
>  
> +enum class DOMAudioSessionType : uint8_t { Auto, Playback, Transient, 
> TransientSolo, Ambient, PlayAndRecord };
> +enum class DOMAudioSessionState : uint8_t { Inactive, Active, Interrupted };
> +
>  class DOMAudioSession final : public RefCounted, public 
> ActiveDOMObject, public EventTarget, public 
> AudioSession::InterruptionObserver {
>  WTF_MAKE_ISO_ALLOCATED(DOMAudioSession);
>  public:
>  static Ref create(ScriptExecutionContext*);
>  ~DOMAudioSession();
>  
> -enum class Type : uint8_t { Auto, Playback, Transient, TransientSolo, 
> Ambient, PlayAndRecord };
> -enum class State : uint8_t { Inactive, Active, Interrupted };
> +using Type = DOMAudioSessionType;
> +using State = DOMAudioSessionState;
>  
>  ExceptionOr setType(Type);
>  Type type() const;

So that these enums can be forward declared in Document.h, rather than 
including the header wholesale.

However, this requires a significant coding style change, both to existing code 
and new code, and as such, it should probably be discussed here. So, what do 
people think? Is the change in coding style (moving class-scoped enums out into 
namespace scope) worth doing if it means a significant increases in compile 
speeds?

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

Re: [webkit-dev] Use of Swift (for bridging) in the WebKit project

[Jer Noble via webkit-dev]

> On Jun 9, 2021, at 11:31 AM, Geoff Garen  wrote:
> 
> In this specific case
> 
>   What is the API we’re trying to call into?

This is calling into the GroupActivities.framework API which was announced at 
WWDC this week.

>   Is using Swift the only way to call into it?

This was true at the time we wrote it, as GroupActivities required using the 
Combine framework, which does not have an Objective-C API. I'm learning that 
this may not be the case in the future. If GroupActivities is modified to not 
require Combine, I will gladly remove the .swift.

>   Is there any way to reduce the use of Swift to only the calls into it, 
> and not the surrounding objects (which all seem to be marked @objc anyway)?

The surrounding objects have to be written in Swift (in order to call Swift 
APIs), but callable from Objective-C/++, which is why they're marked as @objc. 
I believe that they are as minimal as I can make them.

-Jer

> Thanks,
> Geoff
> 
>> On Jun 8, 2021, at 4:27 PM, Sam Weinig via webkit-dev 
>>  wrote:
>> 
>> Hi Jer,
>> 
>> I think it sounds like a reasonable rule to allow Swift for bridging 
>> purposes only, with the caveat that we should prefer Objective-C/C where it 
>> can be used.
>> 
>> The one other place that Swift seems reasonable for WebKit is in the 
>> definition and refinement of Swift bindings to WebKit’s public API.
>> 
>> That is to say, for the time being, we should avoid Swift in tools and core 
>> functionality.
>> 
>> Thanks for bringing this up on the list.
>> 
>> - Sam
>> 
>>> On Jun 8, 2021, at 3:57 PM, Jer Noble via webkit-dev 
>>>  wrote:
>>> 
>>> Hi all!
>>> 
>>> We're working on some new features that currently use APIs exposed through 
>>> Swift. We have not yet approved writing and committing WebKit code in 
>>> Swift, given runtime, library, and just plain mental overhead that comes 
>>> with adding a new language to the project. But I'd argue that doing so for 
>>> the purpose of allowing existing C++ code to call into Swift APIs is 
>>> probably not terrible.
>>> 
>>> Should we relax our "no new language" policy, only for the purposes of 
>>> allowing our core language code to call into APIs in Swift?
>>> 
>>> (ref: https://bugs.webkit.org/show_bug.cgi?id=226757)
>>> 
>>> Thanks, and look forward to hearing from everyone,
>>> 
>>> -Jer
>>> ___
>>> 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
> 

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

[webkit-dev] Use of Swift (for bridging) in the WebKit project

[Jer Noble via webkit-dev]

Hi all!

We're working on some new features that currently use APIs exposed through 
Swift. We have not yet approved writing and committing WebKit code in Swift, 
given runtime, library, and just plain mental overhead that comes with adding a 
new language to the project. But I'd argue that doing so for the purpose of 
allowing existing C++ code to call into Swift APIs is probably not terrible.

Should we relax our "no new language" policy, only for the purposes of allowing 
our core language code to call into APIs in Swift?

(ref: https://bugs.webkit.org/show_bug.cgi?id=226757)

Thanks, and look forward to hearing from everyone,

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