(replies inline to multiple messages) >> I think the biggest unknown is memory management. > > Is this the only thing that's blocking compilation
Unfortunately it's not. Some other problems I ran into: - The Java code has static data with non-constant initializers that depend on each other. For C++ we produce an initializeStatics() function for each class. We'd need to do the same for Rust. It's harder because Rust distinguishes between "static" and "static mut" and only the former can be used as patterns in "match". - The Java code uses "null" in various places. So the translator needs to insert Option<T> wrapping/unwrapping on object creation, field access, etc. - Java and C++ name data members without a "self" or "this" prefix, but arguments and local variables can shadow them. I wrote a special case to handle the Java idiom "this.foo = foo" but it doesn't catch everything. I think we will need a real shadowing analysis, and I don't expect the Rust compiler to catch mistakes because the types will match. - Java and C++ support function overloading by argument count and type; Rust doesn't. I have manually reassigned unique names to the Java functions, but we might need a name-mangling approach to handle constructors. I'm confident that we can solve all of these problems with reasonable effort. What I don't know is how many more we will discover, especially once we get past syntax and name resolution errors. > However, it's probably a good idea to design for a code path without the > off-the-main-thread (or I guess task in Rust) overhead for innerHTML. See > https://bugzilla.mozilla.org/show_bug.cgi?id=959150#c10 Perhaps we can put the "create tree op" methods in a trait, and have one implementation which just applies them directly. Do we need to do script-initiated parsing in the script task in all cases? I was imagining that (similar to COW DOM) we could let the script continue until it touches the DOM again. For document.write it seems impossible due to e.g. <script> x = 2; document.write('<script>x = 3;<'+'/script>'); alert(x); </script> but can this happen with innerHTML? Another thing I would like to understand is how real sites use document.write(), especially cases which are performance-sensitive. It seems like such an obviously bad API compared to DOM manipulation, but I gather it's still widespread. How often is the target the current document vs. an iframe? (If the answer is "nobody knows" then I can look into this.) > So part of the difficulty of document.write comes from the fact that it > has to interact with the script loading / document lifecycle. Therefore > it's going to be hard to get those parts of (any) parser right until we > actually implement a more correct model of document loading. Ideally the > two things would be designed concurrently so that there isn't an > impedance mismatch between the parser and the loading code. That makes sense. What should I read to start understanding the design requirements? keegan _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
