XPConnect uses an unmodified C/C++ compiler, though, right? (So it doesn’t qualify as a language extension per my definition.)
-
-
Replying to @pcwalton
For the most part, yes. Though, it does use an IDL, asm stubs, and other codegen glue too. It's more of an abstraction over GC-ed objects to make them look like "native" refcounted objects.
1 reply 0 retweets 0 likes -
You could potentially make something like it sound in rust with the help of some custom derives / attrs? Nastiest part is probably dealing with JS <-> Native <-> JS cycles.
1 reply 0 retweets 0 likes -
Replying to @kneecaw
My current thinking is to do something like Objective-C, where native->JS handles are very rare and explicitly rooted. Most native objects that hold onto JS objects should be JS objects instead.
1 reply 0 retweets 0 likes -
The more I look into Objective-C the more I realize its design is brilliant—native->managed is nasty, so the entire ecosystem discourages it. As an example, people just don’t put Objective-C objects in C containers and use NSArray instead.
1 reply 0 retweets 1 like -
Replying to @pcwalton
That seems fairly reasonable, assuming you can get good enough ergonomics. You wouldn't want to have to explicitly downcast from an untyped JSValue every time you access a private array member for example.
2 replies 0 retweets 1 like -
I suppose you'd then use a custom attribute to allow describing JS slot layouts with rust-style struct decls, and the rust type system to describe rust-generated JS objects?
1 reply 0 retweets 0 likes -
Replying to @kneecaw
Yep. They’d “look like” Rust objects syntactically. This is basically what C++/CLI does: .NET objects “look like” C++ objects, though they’re very different and have a special pointer sigil (Foo ^ instead of Foo &/Foo *).
1 reply 0 retweets 1 like -
Replying to @pcwalton
It's sorta like a reverse-XPConnect, I suppose. XPConnect makes JS objects "look like" C++/Rust objects (by wrapping them with a refcount), while the proposed approach approach makes Rust objects "look like" JS objects (by storing fields as slots).
1 reply 0 retweets 1 like -
I proposed a similar-ish idea at one point or another for C++, but as we can't inject compiler extensions easily, it'd have to be done in a separate codegen pass, like how we do XPIDL today.
1 reply 0 retweets 1 like
Do you have any references for your proposal? That sounds very interesting! I’m trying to drum up support for this idea myself on the Servo side, and I’m very big on writing DOM components that can be used in both Servo and Gecko too…
-
-
Replying to @pcwalton
I don't think I ever wrote it up, unfortunately. At the time I was thinking of it as a way to reduce heap fragmentation for DOM objects by allowing the GC to relocate them, but I didn't have the time to prototype anything, and wasn't sure if it'd have a positive effect.
1 reply 0 retweets 0 likes -
Replying to @kneecaw
The other nice thing about doing reverse-XPConnect is that the problems with borrowing go away. You don’t borrow slots; you just use get() and set() style methods to get and set their contents as a whole. (If a slot stores a JS object, get() temporarily roots.)
1 reply 0 retweets 1 like - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.