<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [JSC] implement async functions proposal"
href="https://bugs.webkit.org/show_bug.cgi?id=156147#c43">Comment # 43</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [JSC] implement async functions proposal"
href="https://bugs.webkit.org/show_bug.cgi?id=156147">bug 156147</a>
from <span class="vcard"><a class="email" href="mailto:ggaren@apple.com" title="Geoffrey Garen <ggaren@apple.com>"> <span class="fn">Geoffrey Garen</span></a>
</span></b>
<pre><span class="quote">> > I believe we create a new Parser for each parsing operation. I would assign
> > flags to the Parser from the global object at Parser creation time.
>
> I've been looking at doing this --- there are some unfortunate side affects
> (growing the size of every UnlinkedFunctionExecutable, for one).
>
> Is there any good reason not to just use JSC_OPTIONS for this? This would
> make it easy to enable during tests, without growing a bunch of classes</span >
It would be nice to standardize on RuntimeFlags as the single place where we enable or disable features at runtime.
Why does propagating a runtime flag from global object to parser require adding data to UnlinkedFunctionExecutable, and why does using a JSC::Option avoid doing so?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>