<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Parse the entire WebAssembly modules"
   href="https://bugs.webkit.org/show_bug.cgi?id=147393#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Parse the entire WebAssembly modules"
   href="https://bugs.webkit.org/show_bug.cgi?id=147393">bug 147393</a>
              from <span class="vcard"><a class="email" href="mailto:sukolsak&#64;gmail.com" title="Sukolsak Sakshuwong &lt;sukolsak&#64;gmail.com&gt;"> <span class="fn">Sukolsak Sakshuwong</span></a>
</span></b>
        <pre>Thanks.

(In reply to <a href="show_bug.cgi?id=147393#c3">comment #3</a>)
<span class="quote">&gt; In general, we keep one file per class in WebKit. Since these structs are
&gt; separate from JSWASMModule, they should belong somewhere else.
&gt; 
&gt; It would be tedious to use one file per class for each of these structs, so
&gt; let's use a shared file for all of the structs that define the format of a
&gt; WASM tree. How about WASMFormat.h, as you suggested previously?</span >

Fixed.

<span class="quote">&gt; &gt; Source/JavaScriptCore/wasm/JSWASMModule.h:113
&gt; &gt; +    friend class WASMModuleParser;
&gt; 
&gt; &quot;friend&quot; tends toward spaghetti code. We use classes to establish a
&gt; separation of concerns, so that we can think about one class, and change it,
&gt; without worrying about all the other code that uses it. &quot;friend&quot; erases that
&gt; separation and makes our code more brittle.
&gt; 
&gt; Instead of friend, in this case I recommend providing accessors methods for
&gt; these underlying vectors.</span >

Fixed.

(In reply to <a href="show_bug.cgi?id=147393#c5">comment #5</a>)
<span class="quote">&gt; &gt; (In reply to <a href="show_bug.cgi?id=147393#c3">comment #3</a>)
&gt; &gt; &gt; &gt; Source/JavaScriptCore/wasm/WASMModuleParser.h:60
&gt; &gt; &gt; &gt; +    JSWASMModule* m_module;
&gt; &gt; &gt; 
&gt; &gt; &gt; You need to do something to prevent m_module from being garbage collected.
&gt; &gt; 
&gt; &gt; Since WASMModuleParser is allocated on the stack, doesn't that prevent
&gt; &gt; m_module from being GC'd? Do I need to do something extra to protect it?
&gt; 
&gt; In practice, you can probably produce GC safety by allocating
&gt; WASMModuleParser on the stack. But that's a dangerous thing to do because
&gt; there's no way to prevent a future coder from moving WASMModuleParser to the
&gt; heap, and in general, C++ is intentionally agnostic about whether an object
&gt; was instantiated on the stack or the heap.
&gt; 
&gt; I think a better solution is to use Strong&lt;T&gt;.</span >

Fixed. I guess one way to do it without using Strong&lt;T&gt; is probably

JSWASMModule* WASMModuleParser::parse(...)
{
    JSWASMModule* module = JSWASMModule::create(...);
    m_module = module;
    ...
    return module;
}

but it seems very hacky.</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>